The Lenya HTML Form Editor allows to edit the content of XML files within the Web browser. It's only assumption is, that the browser understands HTML forms and <input> and <textarea> tags. Therefore it should be usable under any browser.
The type of editor field to be used, as well as any options concerning the width and heigth, are declared in a descriptor file, accompanying the XML file to be edited. This descriptior file allows to declare the minimum and maximum number of XML-tags of the same name within the hierarchy.
For example we have a "member" document "elvis.xml" of the form
<?xml version="1.0" encoding="iso-8859-1"?>
<member>
<person>
<name>Presley</name>
<prename>Elvis</prename>
<birthday>
<year></year>
<month></month>
<day></day>
</birthday>
</person>
<curriculum>Breaking hearts, is often lonely and looks for love.</curriculum>
<contact>
<address>
<street>Heartbreak Hotel</street>
<town>Graceland</town>
</address>
<emails>
<email>elvis@lenya.com</email>
<email>king@graceland.com</email>
<email>god@rnr.com</email>
</emails>
</contact>
</member>
The corresponding edit descriptor has the form
<?xml version="1.0" encoding="iso-8859-1"?>
<member>
<person>
<name editType="form" size="30" name="Name"/>
<prename editType="form" size="30" maxOccurs="5" name="Prename"/>
<birthday>
<year editType="form"/>
<month editType="form"/>
<day editType="form"/>
</birthday>
</person>
<curriculum editType="text" width="50" height="7">
<contact>
<address>
<street editType="form"/>
<town editType="form"/>
</address>
<emails >
<email editType="form" minOccurs="0" maxOccurs="unbounded"/>
</emails>
</contact>
</member>
Comparing both files, we see that the edit descriptor is simply the "member" XML file with empty tags. The attributes declare how to XML-tags are to be edited, namely:
attribute | possible values | notes |
---|---|---|
editType | "text", "form", "show" | default: nothing is shown |
minOccurs | "0","1","2","3",... | default if not given: 1 |
maxOccurs | "1","2","3",..., "unbounded" | default if not given: 1 |
name | "any name you like" | will be displayed instead of tag name |
All other attributes are provided unchanged to the input field. One could say, that the edit-descriptor is some sort of XML-Schema or DTD. It should be straightforward to use a XML-Schema for the same purpose, if the appropriate editing keywords are added.
Some input fields, namely those of type="text", allow the user to embed XHTML tags in their content, allowing them to influence the representation of the text somewhat, and to provide links to the page, in a relatively free style.
This feature creates also the possibility of the user writing incorrect (non-XML) content, and thus endangering the stability of the application. To guard against this danger, the content of all input fields is checked for well-formedness, and an error message is displayed if there is incorrect markup embedded, while the content is not allowed to be saved.
The check for well-formedness is executed from whithin EditorMainAction.java, before the file gets saved, and checks the whole xml content of the file to be saved. This is probably overkill, and in a future iteration of the development, could be reduced to check only the fields that allow XHTML content. This could be done by ways of providing a method for checking the xml in a utility class, and calling it only when it is needed.
Also, the check for well-formedness is implemented by means of the Cocoon API, and uses the parser that is defined as the parser for Cocoon, which makes it easy to change it (in the cocoon.xconf). However, the Cocoon API does not provide means to get very specific messages as to what the error is, and where it is located in the source document, as it throws a org.xml.sax.SAXException, instead of a org.xml.sax.SAXParseException, which would provide more information. This might change in the future, but until then, only a generic error message can be displayed to the user, which is, at the moment, hardcoded in the stylesheet body.xsl, and is displayed on top of the edit page. This problem could be somewhat defused by parsing element-wise, as decribed in the previous paragraph, and providing the error message located together with the element causing the problem.
html-form-editor.xmap
sitemap.