(i) reusing the bean library as is with <beandef>I think mixing namespaces is what Jelly is all about, in a sense.. Whats bad about the beandef? In fact a useBean would do as well, wouldn't it?
(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.
<useBean xmlns="jelly:core" xmlns:bean="jelly:bean" var="c1" class="org.dada.Customer">
<bean:order>
<bean:product/>
</bean:order>
</useBean>
Personally I always try to avoid depending on anything else than core functionality. For example, use standard Java collections if at all possible before moving to something like commons-collections.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).
Thats why I like (iii) (that had to be said, of course).
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]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
