Although XULUX still needs a lot of work, the graph below gives you a global overview of how the differnt XULUX parts work together.
The core API is currently just the XuluxContext
and all the interfaces
defined to make the system as generic and pluggable as possible.
Since the full gui implementation (except for the Widget abstract itself), is
fully implemented in the layer itself, we currently depend currently on Swing
in the XULUX core. Since this gives problems with being fully gui independend,
the system is going to move some basic widgets to the core and there so called
WidgetHandlers take care of the specifics for that gui layer (eg
swing, swt, awt, html).
To be able to work with the system at all, at least one gui layer must be present.
The Rule Engine and Dataproviders are not necessary to have gui!
The rule engine is also currently part of the core of XULUX.
This engine is very simple and the core relies on it for eg initialization.
Since we want to have Rule Engine API available for custom implementation (eg drools),
we have decided that the current rule engine will stay part of the core in future releases
and this way always available. The future implementation will also allow a mixture of rule
engines to be used in an application, applicationpart or even a field.
Other rule engines you can think of is eg a Scripting Rule Engine.
The DataProvider API is currently not a complete api. The DataProvider API will
take care of feeding data to the gui, storing data from the gui and other tasks
that the data provider may need. In short : XULUX just doesn't care how he gets
the data, it just wants to get it :).
For more information see the Dictionary
documentation.