commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ernst de Haan <er...@ernstdehaan.com>
Subject Re: [Digester] Generic digester patterns?
Date Mon, 06 Aug 2007 06:58:08 GMT
Simon,


> 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.

For a real-world configuraton file I think this is quite typical. At  
least in my experience.

> 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.

My  preference is xmlrules. I think it's great I can split out the  
digester rules in a simple XML-file. But I know xmlrules-support is  
not the preferred approach...

> 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, ...

Indeed; an XInclude-d file is definitely an improvement.

> 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.

Exactly what I was thinking:
- one simple XSD (per digester) for validation;
- one simple XML file for the digester rules (per digester), with  
generic rules.

For now I will just use the non-generic approach, which produces a  
larger file, but works OK and is in fact not a problem at all. It  
works just fine.

Thanks for all the support.


Ernst

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


Mime
View raw message