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

Reply via email to