Hey Simon, thanks for getting back to me.
Hrmmm....I was afraid of that. In fact the exact pattern is
"javerules/rulesets/ruleset/rule/*/message" which matches nothing in my
ruleset.
I did move all the pertinent sub-elements to the outer level, which means
I'm going to have break down and actually write a DTD and use xml
validation. I guess this is all the motivation I need to force me to do
things correctly.
Just out of curiosity, is the RegExRules just broken or simple
not-ready-for-prime-time? After the Extended rules didn't work out, I wasn't
too keen on heading down an even more complicated path so I'll admit I
didn't even try...
I have not looked into the plugins. And now, looking for the plugins docs, I
realized I've made a huge mistake. The "Guide" link goes to a page that
appears to be Javadoc generated...and I thought it was JUST javadocs.
Therefore I didn't scroll down to the actual guide...doh! Man, have I been
working in a vacuum. :) Just now I went to a co-worker and he thought
exactly the same thing. We were just under the impression that Digester was
grossly under-documented and secretly cursing all of you under our breath.
Glad to know how wrong I was. Maybe you could move some of the guide links
up above the class references stuff for those of us too dumb to scroll down.
I don't think the plugins are really related to what I'm doing. I could
probably use a plugin to clean up a few classes here and there. However, the
substitution extensions might be terribly useful, since I'm already using
them by using commons-config to hold all my configurations.
This is my first serious foray into Digester and I put the Jakarta Commons
Cookbook and Apache Jakarta Commons: Reusable Java™ Components onto my
Safari bookshelf, used my download tokens to get the chapters on BeanUtils
and Digester, and a toolbar-level link to the wiki page (thanks!) on my
browser. Since I wasn't smart enough to actually read the guide, I sort of
wandered through the desert blindly for a few days.
I believe I can tell you some things about how I'm using Digester without
describing the domain. Or maybe I'll get fired. :)
My current work implements a java-based rules engine that performs some VERY
basic validations. Currently our customer base uses a desktop app to reach
our backend systems. We're making a struts-based alternative to that. The
customer base uses VBA inside the desktop app to do customizations, and
we're porting the ability to use that VBA on the browser through the use of
browser helper objects (yikes!), but that's just gross. One of the two
primary functions they use this code for is to perform
implementation-specific validations (field X must not be greater than field
Y + field Z).
I'm using digester to build up the rulesets inside a singleton ObjectFactory
that produces an instance of the specific runtime validations for a given
context.
Another part of this is an extension to DynaBeans that lets me define
arbitrary code that generically retrieves data and places them into a
DynaBean instance by intercepting the "get" call of the bean. I use Digester
to generate the my extended DynaClass definitions from XML. I then have an
ObjectFactory that produces instances of the DynaClass.
A third part is another Digester call that parses xml definitions of our
domain data and provides an overall view of the domain data for a given
context. I haven't implemented an ObjectFactory for this yet, because of the
fourth element of the effort.
The fourth and final Digester call processes a services definition file that
ties all the contexts together to another (usually identical) context that
is specific to our application (usually a screen name).
An intercept inside our base-level action class will do a jndi lookup for a
service context based on the current form and if one exists, it will use
that to populate the rules engine instance with the working data (as
DynaBeans) and run the rules against them. The result of the rules should be
"errors" so it's another level of struts validation but behind the action
class because we retain the previous copy of the form bean and we'll pass
that to the rules instance as "previous" and the current form bean as
"current" and so you can make a rule that says 'if current.fieldx <>
previous.fieldx then message("You're not allowed to change fieldx")'.
My boss is sort-of allergic to drools for some reason so he wrote the first
cut of this rules thing and I carried it forward from there. Funny thing is,
if we would have used drools this entire process would have been complete
weeks ago. The drools implementation of the rules engine is something like 3
classes and maybe 100 lines of code. This validation engine is some 40-odd
classes and I don't even want to know how much new code I've written. :)
Thanks again for your help and for suggesting the plugins since that helped
me pull my head from a nether orifice and actually read the guide :)
On 6/23/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2005-06-23 at 22:16 +1200, Simon Kitching wrote:
>
> > It looks like an interesting layer you're building on top of digester.
> > Are you at liberty to discuss what you're trying to achieve?
>
> And by the way, have you had a look at the "plugins" module for Digester
> (example usage is in src/examples/plugins). It *might* be related to the
> kind of stuff you're doing.
>
> Regards,
>
> Simon
>
>
