This page will describe the features that XULUX will have. None of the features are in a ready state at the moment, since we are in a big refactor of the core to seperate out all components that should be pluggable. The main features of nyx as stated on the home page will be explained a bit more in detail.
The core of the nyx system should mainly contain interfaces and a some logic to glue the interfaces together into a working system. Still a lot of work to be done in this area, but most changes will not hurt existing systems.
For now we only have a swing implementation, which is not yet finalized. SWT, AWT and html/servlets are next on the list
A gui handler is the system that actually creates the widgets and activates them. Currently a nyx specific xml format is used. Adding handlers for eg XUL or formats used by others, is already possible, since you currently have to call the handlers manually. We want to move to a more "pluggable" way of using handlers, so nyx can be completely run by not having to call the handlers directly. (eg using NyxRunner specifying a xml'ized configuration file.
The gui designer will be an important part in nyx. It will allow seperation of gui design from business rules. It will also contain an appication generator, which will be based on the selected dataprovider for the project. Since I want to make the gui designer in NYX as a proof of concept for what NYX can do, it will take a while to get this finished. Building of the designer will be focused towards Eclipse integration and if the need is there, there will be a netbeans plugin.
Currently the widgets are kind of focussed on getting the job done, even though not always nicely. The goals is to create basic widgets, that can be extended to any use. A widget should be constructed based on different parts of functionality. There should be a core widget, which just delegates it's behaviour to the handlers specified in an xml configuration for that widget. This way every peace of handling can be delegated or overriden easily if behaviour of the widget should be adjusted.
For now you need to provide data yourself and the dataproviders are not interfaced and pluggable yet. All data can be defined in the dictionary (baseType is the most important one) and strange getters and setters can be specified in the dictionary too.
For now only the internal nyx rule engine is used. We are looking at other rule engines when there is a release of nyx that is usefull for the public.
For easy testing of rules, nyx will provide a test engine, build on top of jUnit. This will probably be solved via a mock gui layer implementation. The goal is to be able to test rules, without the need to see have a gui present.