commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown" <>
Subject Re: [digester] Adding location support
Date Sun, 23 Apr 2006 01:00:37 GMT
On 4/22/06, Simon Kitching <> wrote:
> This feature sounds like an excellent idea to me.
> I think I would prefer the first few patches to be posted to the list,
> for feedback before committing them. But assuming everyone's happy with
> the basic approach/api I'd then personally be happy for you to get stuck
> in and commit the rest directly.
> The namespacing approach might need some thought first. Digester's
> namespace handling for pattern-matching pretty much sucks. This probably
> isn't relevant here, as that's about matching an ELEMENT using a path,
> while you are proposing introducing *attributes* with namespaces, not
> elements that need to be matched by user paths. However I think you
> *are* relying on CallParamRule(int paramIndex, String attrName) handling
> namespaces correctly, so the uri/line/column stuff can be fetched, yes?
> It's therefore necessary to make sure that can indeed be used to handle
> namespaced data correctly.

Ok, I haven't looked into that part yet.  My goal is to make this capability
as transparent to Digester as possible.  In fact,  the code I just wrote
implements a (optional) SAX pipeline (ala Cocoon) that allows a user to add
"Transformers" to modify the SAX events before they hit digester.  I'm
thinking of the Location injection to be simply a Transformer that the user
can create and add to the Digester, so the Digester class won't even know of
its specific existence.

This pipeline opens to doors to greater things, such as multi-schema
support, meaning the code can be written to one XML schema (schema in its
generic meaning), but support multiple older schemas through transformations
that trigger if an older format is detected.  For example, project foo has a
config file format version 1.  For version 2, they add some elements and
move things around.  Rather than requiring everyone to use the new format,
they can just add a transformer that triggers only for version 1 files,
transforming the XML to meet the new format.  The digester rules never know
any different.

The pipeline code, as you'll see when I post the patch, only adds 15 or so
lines to Digester and is itself very small and minimal.

As CallParamsRule, I'm a digester newbie so I'm new to this.  If that rule
doesn't support namespaces, I'll see what I can do about fixing that.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message