Hi Remy,
On Wed, 2003-11-12 at 23:01, Remy Maucherat wrote:
> Simon Kitching wrote:
> > Hi Remy,
> >
> > I'm really keen to have this sort of feature in Digester.
> >
> > I've had this kind of functionality in my local application for some
> > time now, but it's implemented in a rather different manner.
> >
> > Attached is my current implementation, for comparison.
> >
> > Here's the major differences:
> >
> > *
> > Your initial patch only does substitution for SetPropertiesRule.
> > What about CallParamRule, etc?
> >
> > The attached implementation automatically applies to all attributes, and
> > therefore to all rules both built-in and custom. While somewhat less
> > efficient than your current proposal, it isn't likely to be invoked very
> > often (variable substitution is expected to be the exception, not the
> > normal case). See later for a proposed optimisation to the current
> > implementation.
>
> - it could be not very efficient (you reinstantiate all attribute
> lists); JBoss does the exact same thing, and I don't know if it's
> significant, so I chose a lower overhead method; I think I'll try it
> though, since it is more generic and easier to implement
I agree there is an efficiency hit for the implementation I suggest. My
email proposed some improvements to the existing implementation that
should reduce this by at least 50% (depending on how many input elements
actually take advantage of variable substitution).
And if performance is a problem, we could design a custom class which
implements org.xml.sax.Attributes, and reuse the same instance all the
time. The data inside can be structured as Arrays of values; I'm pretty
sure it is possible to create a class that would not need any dynamic
allocation at all to "copy" the attributes data into it. Yes, the
copying is needed but that is no worse than the copying going on when
implementing it in SetPropertiesRule et. al.
> - it doesn't support scoping like Ant does (and is a feature Tomcat
> would use)
Could you explain this, Remy? I don't see what you mean by scoping..
> - personally, I'm used to ${...}, like all Ant users, probably; I don't
> see any reason to add support for customizing this (I don't like featurism)
Anyone else like/dislike the suggestions that:
(a)
there should be some syntax available to suppress variable substitution,
so it is actually possible to pass the string "${" to a method when
variable substitution is enabled?
(b)
the variable marker" char should be customisable?
(c)
multiple sources should be supported?
As I said in a previous email, I'm not sure at the moment that (c) can
be efficiently implemented.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
