From: "Christian Sell" <[EMAIL PROTECTED]>
> > You didn't supply a MyTagLibrary patch.
>
> duh. attached now
Thanks.
> > FWIW the MyTagLibrary implementation doesn't use BeanTagLibrary at all.
> > Though there's a MyBeanTagLibrary that shows how BeanTagLibrary can be
> > reused if required.
>
> MyTagLibrary uses BeanTag and BeanPropertyTag.
Yes.
> I dont see much value in reuse either way (inheritance or using) In both
> cases, you are just pre-registering a root tag.
Not just that - also reusing the nested property processing.
> That can be done easier
> with a statically registered tag (my example), or using the existing
> <beandef> tag.
Agreed. We're splitting hairs here - the <beandef> tag can be used with the
existing bean library to do everything we need.
Your version of MyTagLibrary requires a new Tag implementation per bean
(e.g. CustomerTag) - plus the tag library doesn't use the BeanPropertyTag.
So this XML...
<customer xmlns="jelly:org.apache.commons.jelly.tags.bean.MyTagLibrary">
<order>
<product>
</order>
</customer>
wouldn't actually create any nested properties. You'd have to use 2
namespaces, one to create your customer and one to add the nested
properties. e.g.
<my:customer
xmlns:my="jelly:org.apache.commons.jelly.tags.bean.MyTagLibrary"
xmlns="jelly:bean">
<order>
<product>
</order>
</my:customer>
which while possible is a little hacky - it'd be nice for a custom library
to be a self contained thing.
Though its a mute point really - either approach is suitable. Either
(i) reusing the bean library as is with <beandef>
(ii) deriving from BeanTagLibrary to register new beans
(iii) creating a brand new tag library (and reusing the bean library for
nested properties)
(iv) creating a brand new library and reusing BeanTag and BeanPropertyTag.
Take your pick they all achieve about the same thing.
Downsides of (i) and (ii) is that <beandef> is visible in the XML, which
some folks might not want. Downsides of (iii) is that it requires 2 seperate
namespaces. Downside of (ii) and (iv) is a dependency on the bean tag
library implementation. Additional downside of (iv) is that the
implementation is a bit more code (which through some refactoring of
BeanTagLibrary could be avoided).
I like (i) for general purpose stuff and (ii) or (iv) for implement custom
languages. But each to their own.
James
-------
http://radio.weblogs.com/0112098/
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>