[rules-users] Web client-side rule testing - best practices

[Ronald Albury]

I have always thought of Drools-like systems being server-side engines -
and we have many server-side-only uses for rules.  However, for a good user
experience you should do checking as close to data entry as possible, and
there is a subset of our server rules that are redundant with the rules
governing client data entry (currently embedded in the Web interface as
Javascript).

Has anyone established a good pattern for using Drools for client-side
testing?  I'm guessing that we would need some sort of per-field Ajax
communication back to the server ... but this means per-field communication
(not good for our agents on dial-up or with slow links), and it also means
structuring our rules such that we can easily access only the appropriate
rules.

Would I, for instance, need a separate Fact object type for each field?
This seems like it would really complicate the rules - we have about a
dozen basic data structures for our server-side Facts, and each data
structure will have multiple attributes.  I don't look forward to dealing
with a couple hundred Fact types.

Would I need some sort of flag on our data structures to include in the
Fact which restricts the testing to only the field that was just entered?
This would seem to complicate the understanding of our rules.  Some rules
(even UI rules) depend on a combination of facts - so would it be a 'set'
of flags?  This seems to be moving close to the first idea (separate Fact
object types ... which seems more efficient).

So ... as you can see, I am thrashing about a bit trying to find the
correct pattern.  Can someone save me a bunch of time and bad code by
sharing their best practice with me?

Thanks,
   Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20111205/0c7f29f2/attachment.html