Two ways for getting data out from the engine's munching:

(1) You set up a global object alertUser which provides just that service,
so it can be done with a rule:

rule "x"
when
   $ve : ValidationError()
then
   alertUser.notify( $ve );
   retracT( $ve );
end

(2) You run a query from Java code after return from fireAllRules

query "allValidationErrors"
  $ve : ValidationError()
end

The Java code for running the query is in the Expert manual. You
can, of course, retract just as well from Java.

-W


On 12 August 2010 10:45, Stephen Mcgruer <s0840449@sms.ed.ac.uk> wrote:
Apologies, where I use (Java) I do indeed mean the Java code between
calls to fireAllRules(). I'm not entirely sure about how you meant to
do it in rules, but how do you then report back to the user that there
is a problem? The Java code that calls fireAllRules() has to be able
to get errors and then pass them back to the webpage (yay for a
project structure which requires me to communicate with the front end
by generating XML JSP pages as replies to URL requests from the PHP
code which runs the website...)

Cheers,
Stephen

Quoting Wolfgang Laun <wolfgang.laun@gmail.com>:

> By "(Java)" do you mean Java code between calls to fireAllRules() or Java
> code
> in RHS? I think that what you describe in items 5, 6 and 7 can very well be
> written as rules, based on a Validation object inserted at the time the
> actual
> operation is done in WM. It should contain:
>    - links to the old, or new, or both, Fact objects
>    - the validation status (OPEN, VALID, INVALID)
>
> Need a more detailed outline?
>
> -W
>
> On 12 August 2010 10:08, Stephen Mcgruer <s0840449@sms.ed.ac.uk> wrote:
>
>> Hi there,
>>
>> My project uses Drools to (among other things) validate new
>> facts/updates to old facts, according to a set of rules. (For example,
>> we might have a rule that says "No two people can be named the same
>> thing".) Our method of validation and error reporting was originally
>> chosen for a stateless session (before we had the requirement of doing
>> checks like the above), and I feel I've had to hack it a bit much to
>> get it working with stateful sessions. The current methodology is:
>>
>> 1. (Website) The user inserts/updates a fact.
>> 2. (Java) If the fact is new, an object is created for it. If it is an
>> update, the pre-existing object is fetched from the object repository
>> (the interface to the database) and a backup copy of the object is
>> taken.
>> 3. (Java) This fact is either inserted into the KnowledgeBase (KB) or
>> a pre-existing fact in the KB is updated depending.
>> 4. (Rules) If the new/updated object fails a validation rule, it will
>> be retracted and a ValidationError object will be inserted into the KB.
>> 5. (Java) The code then searches for ValidationError objects that
>> match the just inserted/updated object. If it finds any it records
>> them and then retracts them from the KB.
>> 6. (Java) If there are no errors, then that's it - a success report is
>> generated and passed back to the website.
>> 7. (Java) If there were errors, then if the user was updating a fact
>> the backup of it (before the changes) is inserted back into the KB.
>> The website is then passed a failure report.
>>
>>
>> It just feels very hacky to do so much manual insertion/retracting
>> from the Java side of the code.
>>
>> So, is there a 'correct' way to do stateful validation? And does our
>> current way even work, or are there hidden problems that we've not
>> spotted?
>>
>> Cheers,
>> Stephen
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>



--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



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