Just completed a tiny DTD for DocBook corresponding to the small set of tags for which I had written the XSLs. I am so glad it works! (http://dev.gentooexperimental.org/~n9986/beacon/editor/ works best with firefox)
Now on it is just a matter of adding more elements to get a richer tag-set for DocBook till the mid-term evals. The basic infra is all set up (will try to keep improving usability though).
Also added a brand new and better CSS.
On the other side I think I should try and get more community involvement into developing the editor as the number of DocBook elements is *huge*.
I'll start by explaining what beacon is and how it works.
Beacon is a What you see is what you mean editor which relies heavily on XSL for XML to HTML conversions and vice-versa.
Most of the work involved in making a plugin is writing the two XSLs. One is required for converting the XML to HTML so that it can be displayed in the browser. And the other for converting the HTML back to XML. All these operations are done on the server side using PHP (or Python).
One may wonder, why rewrite XSLs if they already exists, like for Docbook for example. The reason is that Beacon needs some 'hooks' in the generated HTML so it can pick up the nodes using Javascript. This is required to do multitude of tasks like rendering inline editors, maintaining structural sanity, addition/deletion of new nodes, etc. Since HTML and Docbook XML tags are very different, there needs to be some way to map the XML tags over to HTML. These hooks are done using title attribute on tags. So for example, the tag will be rendered in HTML as:
p title = "docbookPara"> Somethings are best with a title /p >
Title tags tend to be most unobtrusive here and works well for DOM manipulation which is made even easier thanks to jQuery.
Once the HTML has been rendered, some Javascript magic makes it editable via inline editors of various types. We are still working on the node adding/deleting feature. Once that is done we will have a more or less a complete editor.
The validation of the generated HTML is kept in check via a Javascript based DTD.
So the user cycle of Beacon is:
new document -> XML -> HTML -> XML
All ajax-y communication is handled by JSON (except for file upload which uses an iframe of course).
Since its a web based it relies completely on Ajax for any post first page load. The UI is pretty much like a desktop Application with Tabs, sidebar etc.
To sum it up, a plugin now requires:
I will write a tutorial on how to make a plugin for docbook next. Will be nice if folks chip in to get in as many tags supported as possible.
Now on it is just a matter of adding more elements to get a richer tag-set for DocBook till the mid-term evals. The basic infra is all set up (will try to keep improving usability though).
Also added a brand new and better CSS.
On the other side I think I should try and get more community involvement into developing the editor as the number of DocBook elements is *huge*.
I'll start by explaining what beacon is and how it works.
Beacon is a What you see is what you mean editor which relies heavily on XSL for XML to HTML conversions and vice-versa.
Most of the work involved in making a plugin is writing the two XSLs. One is required for converting the XML to HTML so that it can be displayed in the browser. And the other for converting the HTML back to XML. All these operations are done on the server side using PHP (or Python).
One may wonder, why rewrite XSLs if they already exists, like for Docbook for example. The reason is that Beacon needs some 'hooks' in the generated HTML so it can pick up the nodes using Javascript. This is required to do multitude of tasks like rendering inline editors, maintaining structural sanity, addition/deletion of new nodes, etc. Since HTML and Docbook XML tags are very different, there needs to be some way to map the XML tags over to HTML. These hooks are done using title attribute on tags. So for example, the tag will be rendered in HTML as:
p title = "docbookPara"> Somethings are best with a title /p >
Title tags tend to be most unobtrusive here and works well for DOM manipulation which is made even easier thanks to jQuery.
Once the HTML has been rendered, some Javascript magic makes it editable via inline editors of various types. We are still working on the node adding/deleting feature. Once that is done we will have a more or less a complete editor.
The validation of the generated HTML is kept in check via a Javascript based DTD.
So the user cycle of Beacon is:
new document -> XML -> HTML -> XML
All ajax-y communication is handled by JSON (except for file upload which uses an iframe of course).
Since its a web based it relies completely on Ajax for any post first page load. The UI is pretty much like a desktop Application with Tabs, sidebar etc.
To sum it up, a plugin now requires:
- Couple of XSLs
- Javascript based DTD
- Some trivial PHP code
- CSS + some template XMLs
I will write a tutorial on how to make a plugin for docbook next. Will be nice if folks chip in to get in as many tags supported as possible.
