Proposal number : ? Proposal title : Editor Enhancements
| Date | 2008/06/20 |
| Contact(s) | Simon Pigot, Francois-Xavier Prunayre |
| Last edited | Timestamp |
| Status | draft, in progress |
| Assigned to release | 2.3 |
| Resources | Available - some parts may be moved to later release if not ready for 2.3 |
Overview
A. Enhancements to the current GN editor:
- Ajax techniques on existing editor controls (add, delete, up, down) and tabs
- New Ajax controls for: choosing a parent metadata record (on parentIdentifier), element re-use through xlinks including resolution and caching (xlink'd info cannot be edited, resolved before saving/check), lookup service information for transferOptions from 19119 records, separate control and service for FileUpload, thumbnails button to show at graphicOverview position in metadata record, additional button at top of form: add child (duplicate with parentId set to current record)
- XSD validation messages available as controls on elements as well as in report screen
- User selected element attributes (may be later - version 3.0)
- Separation of editing and viewing functions (may be later - version 3.0)
B. Support for other editors
Proposal Type
- Type: User interface and core functionality additions
- App: GeoNetwork
- Module: DataManager (support new services), EditLib (enhancements), Metadata Services, Jeeves, metadata XSLTs
Links
- geonetworkui proposal
Voting History
- None yet
Motivations
The current GN editor is a generic – its interface is built by parsing a set of XSDs, combing this info with the XML document to produce a metadocument, then rendering the XML using the metadocument as an HTML form. The rendering is done by XSLT and a small amount of javascript. It works with almost any schema that GN can parse.
The motivation for this proposal is to improve interactivity and functionality of the GN generic editor. At the same time it is clear that a generic editor is not suitable for everyone and that GN needs to support alternatives. The second motivation for this proposal is to support external editors – one way this can be done is to permit serviced-based access to the metadocument format used by the GN generic editor.
Proposal
Part A
Components:
1. Store XML + XSD info (the metadocument) in the session – operations maintain the metadocument until save.
- Add button – server builds only the element to be added, returns it via Ajax call to the javascript which adds it into the form.:
- Delete button – server removed element and returns geonet:child via Ajax call to the javascript which adds it to the form.:
- Up/Down – server swaps elements, Ajax swaps elements in the form and controls.:
2. HTML form is not submitted until save/save and close/check – allows reset button to really work as required.
3. Re-engineering the XSLT layer to just render the HTML – decisions about what to show are to be made in the javascript layer. XPaths are used as unique identifiers. Example: the new XSLT layer for the editor produces add, delete, up and down controls for any element (where this make sense) – the JavaScript decides which if any to make visible/invisible when operations take place. Example: the tabs in the viewer/editor. The new XSLT layer is no longer responsible for rendering a particular tab, instead the whole form is rendered and a set of XPaths describing the elements that should be visible/invisible (stored as an XML file) are passed by the XSLT to the javascript to display the elements relevant to the tab. Advantage: makes it easier to support profiles.
4. XSD validation messages available to the editor as alert controls – schematron error messages are already available via an additional icon. The JDOM elements involved in validation errors can be obtained through a callback on validation – this has been done in Jeeves but controls are not yet being added to the editor by the XSLT.
5. Element Attributes – currently attributes of metadata elements that are optional (eg. xlink:href) can only be suggested in the schemaSuggestions file – picking up new suggestions requires that GN be restarted. Furthermore, attributes are not rendered automatically on some elements – a special template for that element has to be added to the appropriate XSLT to render attributes. This component will finish the implementation of the geonet:attribute metadocument element (labelled FIXME). Following the strategy in 3, attributes will be rendered by the XSLT as HTML, the javascript will decide which ones are visible/active.
Part B
No single editor can satisfy all users. An example of a plug-in GUI that replaces both the javascript layer and the XSLT layer used for the editor is the current Xforms based editor proposal. This editor runs external to GN (in Orbeon Xforms) and uses GN services to retrieve selected metadata documents plus editing information from GN's XSD parser, combined as a metadocument. Currently, after this editor has finished with the document, it is stored external to GN. However, the document could be returned to GN using any of the services GN currently provides.
Two services are planned (and available for development in the BlueNet MEST):
- xml.metadocument.get?uuid=<uuid> - a service to retrieve the initial XML document plus XSD based editing information (a metadocument)
- xml.metadocument.snippet?parent=<parent_element_name>&child=<child_element_name>&schema=<schema_name> - a service to retrieve elements not in the initial XML metadocument (a 'snippet' = a small piece of something)
Backwards Compatibility Issues
None - Xlinks will be resolved before saving.
Risks
Participants
- As above
