commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mykel Alvis <mykel.al...@gmail.com>
Subject Re: Digester wildcard question
Date Thu, 23 Jun 2005 16:23:03 GMT
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 <skitching@apache.org> 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
> 
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message