As stated in the howitallworks document, nyx always comes bundled with the internal rule engine, which is driven from the XuluxContext. Work is being done to make create an easy to extend API from the current rule processing paradigm. The order of rule processing is the order in which rules are added to a widget or part. This will make sure we can use the rules internally and set a certain state before other rules are being processed.
In the future there will be more rule engines to choose from.
The first one on the list is drools,
make the rule engine JSR-94 compliant, so
other rule engines can be easily connected to XULUX.
Also a scripting rule engine will be created, so you can use eg Groovy, Jython, BeanShell or
other scripting engines that work with a Java environment.
The internal rule engine is handled by the XuluxContext, which is the main
entry point for XULUX. (For a beginning of the API, see the
RuleEngine Interface source.
The NyxRuleEngine is used internally by Xulux to initialize widgets and other purposes.
(eg the table needs to stop editing when a user leaves a cell in a table that is editable).
The next sections will go into more detail about when rules are processed on how they
are processed.
Every rule must implement the IRule interface To make life easier, we also provided the Rule class, which is an abstract implementating not heavily used methods or generically used methods. The explenation in the following section is assuming you extend Rule, since the experience is that no one has to overrideIRule directly for normal XULUX use, which leaves us with two methods that need implementing : pre and post.
pre gets called when initializing the part
post gets called when destroying the part. A part will be destroyed when closing the window,
someone hit the ok or cancel button, or called the destroy() method on the part.
pre gets called when entering a field or when another field has been edited.
post gets called when leaving a field, so when possibly data has changed.
This needs some attention, since a lot of rule processing is done unecessarily
So if you have a part with 10 fields, on startup all pre rules will be called of the 10 fields.
After the user edits a value, the post of that field will be called and the pre of the other 9
fields, so they can update their value accordingly.
Note : You can also specify dependencies, which will cause the value of the widget
to automatically be updated in case of a value changed. This way you don't have to create
rules for cases like this. (TODO : Link to other docs explaining this..)
Sometimes there is a need to stop the normal rule processing as explained in the FieldRules section. You just don't want 9 pre rules fired, when eg there is an invalid value entered. To solve this problem, you can call stopAllRules() to stop processing of any more rules after the current rule has finished processing. The stopAllRules method can be called like this :
request.getPart().stopAllRules();