This document is part of the elaboration phase and describes the configuration mechanisms used in the editor.
As stated in the Vision document the editor embeds three levels of configurability , which are the core level, plug-in level and macro level.
XSS stands for XML Style Sheet, and is an XML-based CSS-like stylesheet language. Its main purpose is to allow to describe structured, heritable and extensible style attributes to configure the display of elements, which is actually made by the view extensions.
As mentioned before, configuration of the editor can be made on different levels:
- Core level which is done using the a file which implements the
Configuration
schema. This configuration file includes three sub-formats:
- An XSS stylesheet to define CSS-like attributes for the elements to be displayed.
- A View list which defines the different view classes that will be used and which parameters are given to the constructor.
- A schema translation which serves as a basis for element meta-information, which is actually is its schema constraints, associated view and XSS style.
- User level configuration which is done through macros that hook at specific application events, such as element insertion, deletion or change.
Most of the graphical configuration can be done with XSS, but views may sometimes require additional configuration. For example it is not really convenient to make a view plug-in for each element that has a specific way of representing its content. It would be rather helpful to allow the XMLViewFactory
to post-configure create views.
Some view may also require behaviour configuration, eg. specific event listeners. In this case it is also awkward to use pure-Java extensions as it would imply to write one class per listener which can get things pretty messy.
In this perspective scripts could be used in correlation to XSS to make post-configuration of views which is not available otherwise. These scripts could be implementation of an interface or subclasses of a class that allows to configure a given view using a given element. Basically the main method would be View configure(View view, Element element)
and would return a configured version of the view. We could think of a class implementation that would provide reflexion based mechanisms to infer the configuration method to be used.
For example the conf_View
method would be the configuration method for elements of namespace conf
and of name View
. Elements with unspecified namespace would be _View
.