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

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users