Two ways for getting data out from the engine's munching:<br><br>(1) You set up a global object alertUser which provides just that service,<br>so it can be done with a rule:<br><br>rule "x"<br>when<br> $ve : ValidationError()<br>
then<br> alertUser.notify( $ve );<br> retracT( $ve );<br>end<br><br>(2) You run a query from Java code after return from fireAllRules<br><br>query "allValidationErrors"<br> $ve : ValidationError()<br>end<br>
<br>The Java code for running the query is in the Expert manual. You<br>can, of course, retract just as well from Java.<br><br>-W<br><br><br><div class="gmail_quote">On 12 August 2010 10:45, Stephen Mcgruer <span dir="ltr"><<a href="mailto:s0840449@sms.ed.ac.uk">s0840449@sms.ed.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Apologies, where I use (Java) I do indeed mean the Java code between<br>
calls to fireAllRules(). I'm not entirely sure about how you meant to<br>
do it in rules, but how do you then report back to the user that there<br>
is a problem? The Java code that calls fireAllRules() has to be able<br>
to get errors and then pass them back to the webpage (yay for a<br>
project structure which requires me to communicate with the front end<br>
by generating XML JSP pages as replies to URL requests from the PHP<br>
code which runs the website...)<br>
<br>
Cheers,<br>
Stephen<br>
<br>
Quoting Wolfgang Laun <<a href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>>:<br>
<br>
> By "(Java)" do you mean Java code between calls to fireAllRules() or Java<br>
> code<br>
> in RHS? I think that what you describe in items 5, 6 and 7 can very well be<br>
> written as rules, based on a Validation object inserted at the time the<br>
> actual<br>
> operation is done in WM. It should contain:<br>
> - links to the old, or new, or both, Fact objects<br>
> - the validation status (OPEN, VALID, INVALID)<br>
><br>
> Need a more detailed outline?<br>
><br>
> -W<br>
><br>
> On 12 August 2010 10:08, Stephen Mcgruer <<a href="mailto:s0840449@sms.ed.ac.uk">s0840449@sms.ed.ac.uk</a>> wrote:<br>
><br>
>> Hi there,<br>
>><br>
>> My project uses Drools to (among other things) validate new<br>
>> facts/updates to old facts, according to a set of rules. (For example,<br>
>> we might have a rule that says "No two people can be named the same<br>
>> thing".) Our method of validation and error reporting was originally<br>
>> chosen for a stateless session (before we had the requirement of doing<br>
>> checks like the above), and I feel I've had to hack it a bit much to<br>
>> get it working with stateful sessions. The current methodology is:<br>
>><br>
>> 1. (Website) The user inserts/updates a fact.<br>
>> 2. (Java) If the fact is new, an object is created for it. If it is an<br>
>> update, the pre-existing object is fetched from the object repository<br>
>> (the interface to the database) and a backup copy of the object is<br>
>> taken.<br>
>> 3. (Java) This fact is either inserted into the KnowledgeBase (KB) or<br>
>> a pre-existing fact in the KB is updated depending.<br>
>> 4. (Rules) If the new/updated object fails a validation rule, it will<br>
>> be retracted and a ValidationError object will be inserted into the KB.<br>
>> 5. (Java) The code then searches for ValidationError objects that<br>
>> match the just inserted/updated object. If it finds any it records<br>
>> them and then retracts them from the KB.<br>
>> 6. (Java) If there are no errors, then that's it - a success report is<br>
>> generated and passed back to the website.<br>
>> 7. (Java) If there were errors, then if the user was updating a fact<br>
>> the backup of it (before the changes) is inserted back into the KB.<br>
>> The website is then passed a failure report.<br>
>><br>
>><br>
>> It just feels very hacky to do so much manual insertion/retracting<br>
>> from the Java side of the code.<br>
>><br>
>> So, is there a 'correct' way to do stateful validation? And does our<br>
>> current way even work, or are there hidden problems that we've not<br>
>> spotted?<br>
>><br>
>> Cheers,<br>
>> Stephen<br>
>><br>
>> --<br>
>> The University of Edinburgh is a charitable body, registered in<br>
>> Scotland, with registration number SC005336.<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> rules-users mailing list<br>
>> <a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
>><br>
><br>
<br>
<br>
<br>
--<br>
The University of Edinburgh is a charitable body, registered in<br>
Scotland, with registration number SC005336.<br>
<br>
<br>
<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</blockquote></div><br>