commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From simon <>
Subject Re: [Digester] Generic digester patterns?
Date Fri, 03 Aug 2007 08:10:21 GMT
On Fri, 2007-08-03 at 08:48 +0200, Ernst de Haan wrote:
> Simon,
> Your in-depth answers are very much appreciated!
> > I'm not quite sure what you mean by "re-use" here.
> >
> > What you're trying to implement isn't that common I think.  
> > Generally it
> > is known what child xml elements a particular xml element can have, so
> > writing explicit rules isn't a problem. Yes, the rules need  
> > updating if
> > a new child element must be supported, but in general the java code
> > needs to be updated anyway (eg to add a new setter method on the  
> > parent
> > class) and everything needs to then be retested so having to modify  
> > the
> > digester rules at the same time doesn't seem to me to be a big  
> > concern.
> Well, in a typical configuration file, there are a lot of common data  
> types used. For example, in a configuration file for a user interface:
> - text string
> - integer number
> - color
> - font
> - etc.
> These data types could be used in many different places in the  
> document, e.g.:
> <Config>
>     <Background><Color ... /></Background>
>     <TitleText><Font ... /></TitleText>
>     <SubtitleText><Font ... /></SubtitleText>
>     <LabelText><Font ... /></LabelText>
> </Config>
> It works when I resort to having one pattern for every higher level  
> element (Background, TitleText, etc.). But I would prefer to use  
> SetNesterPropertiesRule in combination with matchers for the lower- 
> level elements (Color, Font, etc.)
> I hope this is a better explanation of what I meant to bring across...

Ok, I see what you mean. I don't think this is a very common scenario
(the same tags occurring with different parent tags) but I can see it
would be annoying to have to repeat the rules for each parent.

When using the direct java API for digester this isn't a problem; you
just write a subroutine that takes a pattern "prefix" and generates a
set of rules. Then you call that subroutine with "Background",
"TitleText" etc as parameters.

Perhaps the closest equivalent in xmlrules is to use xinclude or a DTD
entity? ie define a block of rules for color/font etc then reference
that block from within pattern blocks for background, titletext, ...

Using leading/trailing wildcards is not quite the same thing; with
wildcards things can go wrong if the user creates unexpected xml (eg a
Color tag directly under config). However if you're also validating the
input xml that problem can be ignored. So simply using one of the
non-default Rules implementation should also do what you want I think.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message