No never noticed the names, its just I'm straight out of bed without
coffee having done a long stretch of coding and I had my black humour
hat on. Everything is A-OK.
Mark
Hamu, Dave wrote:
Okay, now I understand what is going on... Either someone is pretending
to be Mark Proctor or Mark and Adrian are long time adversaries. If the
situation is the former, then I suggest we find out how to stop it... If
it is the latter, then I think that these personal wars should be waged
somewhere else.
IMHO!
- Dave
-----Original Message-----
From: Mark Proctor [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 10, 2005 6:58 AM
To: [email protected]
Subject: Re: [drools-user] input validation in rules used by JSR-94
clients
If you are going to assert a logging instance I suggest you go outside
put your head on the road just after the curb and wait for a bus to come
along - will be less painfull.
If you can't use application data, the maybe just a static reference to
an imported class?
Mark
Adrian Bigland wrote:
Thanks for the reply, Mark.
I didn't want to use application data - I want my clients to use the
same code for any JSR-94 compliant rule engine. My immediate aim is to
try out several implementations with my application, to run
performance tests and just to see the different rulefile styles.
JRules, for example, doesn't have any way (that I've come across so
far) to hook up rule execution provider property map settings to its
rule parameter system (which seems to me to be the equivalent of
application data in JRules).
So I need to rely on asserting things into working memory for that
reason.
Anyway, validation would still be a problem with application data,
wouldn't it? Maybe even worse because at least a rule that only fires
if the logger is there can never throw a NullPointerException because
it is missing...
Mark Proctor
<[EMAIL PROTECTED] To:
[email protected]
us.org> cc:
Subject: Re:
[drools-user] input validation in rules used by JSR-94 clients
10/11/2005 13:43
Please respond
to user
Don't put the logger in as a fact use ApplicationData to inject it
into conditions and consequences without it having to be in the
WorkingMemory.
Mark
Adrian Bigland wrote:
Hi all,
I'm writing Drools into my application through the JSR-94 API, and
I've been considering how to deal with required inputs.
For example, I want to add a logging component to working memory so
that
I
can create a good explanation of the results of the rule session. I
need
to
match this as a parameter to make it available in the rule
consequence.
If
the user doesn't add a logger, none of the logging rules will fire.
It would be better if I could fire a rule that returned some kind of
well-defined error state if the logger is missing, for example
asserting
an
error object or something.
There doesn't seem to be a way of matching an absence of an instance
of a class in the rules - in fact, the meaning of such a rule is not
entirely clear.
One way I tried to do this was to count the number of loggers - and
assert
the count as a fact. A rule can match this fact and assert an error.
The only trouble was that I had to implement modes and mode changes
in the rules as well; the scaffolding code was large enough that it
destroys the most important benefits of using a rule engine to begin
with, i.e.
recording business logic in a concise and manageable way.
Has anyone tackled this? Am I missing a better approach?
I am currently thinking of simply unit testing the clients to check
that the inputs match the current version of the rules, and
programming the clients defensively.
This also started me thinking about strategies to manage change in
rules.
How do you make sure that old clients get a decent error state if
they
run
rules that they no longer know how to make good inputs for. Here I
decided
that the best approach was a good versioning system, with major
version changes indicating that a client is no longer 'binary
compatible' with a set of rules. Whatever you do, because rules and
code are separate, you will always have to be careful when deploying
them that the clients can call rules properly, and that the results
still mean the same thing that the client thinks they mean...
*********************************************************************
* This e-mail and any attachment is intended for the named
addressee(s)
only, or person authorised to receive it on their behalf. The content
should be treated as confidential and the recipient may not disclose
this message or any attachment to anyone else without authorisation.
Unauthorised use, copying or disclosure may be unlawful. If this
transmission is received in error please notify the sender immediately
and delete this message from your e-mail system. Any view expressed by
the sender of this message or any attachment may be personal and may
not represent the view held by First Choice Holidays PLC and its
subsidiaries.
All electronic transmissions to and from First Choice are recorded,
may be monitored and are scanned for viruses and content. E-mails
containing viruses will be deleted without notification. Whilst we
maintain virus checks on inbound e-mails we accept no liability for
viruses or other material introduced with this message.
All companies form part of the First Choice Holidays PLC group of
companies.
First Choice Holidays PLC Company Registration No: 48967 (England)
Registered Office: First Choice House, London Road, Crawley,
WestSussex
RH10 9GX
*********************************************************************
*
