commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: [digester] initial code for Digester2.0
Date Thu, 03 Feb 2005 10:57:30 GMT
Hi Oliver,

I look forward to seeing your ideas on stringifying trees of elements.

> > 
> > The Rule (Action) classes interact with domain-specific (user) classes
> > via BeanUtils and reflection. I don't see any alternative, except for
> > the "pre-processor" type xml mapping tools, or runtime bytecode
> > generation, neither of which are really Digester's domain.
> 
> Well, there it is, my reflection. So we had a misunderstanding. The
> options you name are worse than refelection, I agree, but why using
> the BeanUtils in the first place? Isn't plain refelction sufficient?

Well, I don't believe pre-processing is "worse" than digester; it can be
a great solution in some situations. And for the rest, there's
Digester :-)

Digester uses BeanUtils to do type-conversion (via its ConvertUtils
component), converting the strings extracted from the xml to whatever
types the target methods take.

BeanUtils also treats DynaBean classes as if they were normal Java
classes, which is needed for at least one very important Digester user:
struts.

The reflection stuff we use from BeanUtils is only a few dozen lines so
I guess we could import that into Digester itself. However the
ConvertUtils stuff has a lot of code for typeconversion that I would be
reluctant to duplicate. Maybe it's worth having a look at the new
"morph" project as an alternative; it's more tightly focussed on
typeconversion than BeanUtils.

> > 
> > Hmm.. If we had a class that implements RuleManager that always returns
> > a custom Action no matter what the path, then all events would be
> > forwarded to the user-provided action, where the user can call
> >    context.getMatchPath()
> > to access the current path, and determine from there what operations to
> > perform.
[snip]
> > 
> > Thoughts?
> 
> Looks good. However, we would need code that does the same as the
> default rule manager  in getMatchingActions to match relative paths as
> well. xmlio uses the same path syntax as digester2 anyway.
> 
> I will provide something for this as well.

Excellent!

> > I've not thought too much about obj->xml, and anyway Betwixt has that
> > reasonably well covered as far as I know.
> 
> The xmlio out part is much less than obj->xml, but rather a set of
> helpers on a low level. It also addresses byte encodings which has not
> been thought of in many XML printing solutions.

Hmm.. not sure what to do with this code, then. But I'm pretty sure
Digester is not the right home for it...

> 
> > If you mean having some debug Action that is triggered *for every
> > element seen* in addition to the ones whose patterns actually match,
> > then that can be done fairly easily by subclassing a Rules (in
> > digester1.x) or RuleManager (in digester2.x) class. I guess we could
> > build it in to the default class though...
> 
> This would fit into the xmlio matching above: have an action that is
> called unconditionally. This could be useful in many scenarios.
> Shouldn't this be part of the default rule manager?
>  

There are usecases for having a set of actions that is returned if no
pattern is matched. In particular, it is nice to be able to generate an
error, "unrecognised element", if you are very fussy about the input. I
would definitely like to add this to DefaultRuleManager. And this
feature would fit the xmlio scenario fine.

Having a set of actions that are returned *in addition to* any others is
possibly more controversial. There was someone looking for exactly that
on the digester user list a while ago, wanting to execute
SetNestedPropertiesRule for each element. I'm not so convinced this is a
good idea, though: seems awful easy to shoot yourself in the foot!

Apart from the "debugging" scenario you mention, I can't see a usecase
for having an action that is returned *in addition to the other matching
actions*. And I generally do debugging by enabling commons-logging
output rather than write custom debugging actions anyway. Can you think
of some usecases where this would be useful?

Note also that currently RuleManager can return prebuilt lists when
match is called; no List object needs instantiating. However if "always
present" actions have to be inserted into each list, then a new List
object is required to be created for each match call.

Cheers,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message