9:38 a.m.
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
10:36 a.m.
Perhaps it's helpful - here's the
link<http://members.inode.at/w.laun/drools/DomainSpecificLanguages/DomainSpecificLanguages.pdf>to
the paper backing my talk at this year's Rule
Fest <http://rulesfest.org/>;. Section 4 is about data validation.
-W
2011/12/5 Ronald Albury <ronalbury(a)gmail.com>
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
12:32 p.m.
I thought I should clarify something. I am not looking for Drools to deal
with such UI-specific issues as enabling and disabling fields, what screen
to show next, etc.
Rather, we are developing a rich set of rules on the server to validate
fully populated data structures that we get from multiple sources. There is
a subset of those rules which apply to the UI (e.g. regular expression,
value ranges, etc). I am trying to: a) avoid having multiple versions of
the rules (one for the server and a different one, in Javascript, for the
client); b) avoid waiting until the user submits the data to the server to
provide them feedback from the shared rules.
The question is, are there best practices for: a) designing the rules such
that they can handle both cases (field validation and record validation); b)
connecting the Web browser to the server (e.g. Ajax) to support this
testing.
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-Web-client-side-rule-testin...
Sent from the Drools: User forum mailing list archive at Nabble.com.
3:12 p.m.
Here's what I'm coming up with on my own.
I have a dozen PoJo's for my server record structure, and I am subclassing
them all off of an abstract class that has:
/ private HashSet<String> modified = new HashSet<String>();
private boolean allFields = false;
public boolean fieldWasModified(String name) {
boolean result;
result = allFields || modified.contains(name);
return result;
}
protected void markModified(String name) {
String fieldName = name;
if (name.startsWith("this.")) {
fieldName = name.substring(5);
}
modified.add(fieldName);
}
public void markAllModified() {
allFields = true;
}/
I have modified the 'setter' template in the PoJo project to generate calls
to markModified:
/${field} = ${param};
setModified("${field}");/
My rules now test if a field is modified:
/rule "XmAddress city RegExp"
when
$a : XmAddress(fieldWasModified("city")
&& city not matches "^[A-Za-z ]{1,25}$")
then
$a.addError(drools.getRule().getName(), "Invalid city");
end/
The Web client will use Ajax to create a new object and set record
attributes, as appropriate, and then call the rules.
At the end when I submit the entire record for testing on the server, I
first call markAllModified.
I understand that this will not handle cross-field rules (unless I include
both fields in the Ajax call), but it seems like it will handle most of my
standard data entry edits in a consistent manner across the UI and the
server.
Please provide feedback ... remember I'm a newbie so please make your
criticism constructive.
Thanks
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-Web-client-side-rule-testin...
Sent from the Drools: User forum mailing list archive at Nabble.com.
4770
days inactive
4770
days old
3 comments
3 participants
participants (3)
-
ronalbury -
Ronald Albury
-
Wolfgang Laun