commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: [jelly] taglib implementation questions
Date Tue, 21 Jan 2003 16:34:20 GMT
From: "Christian Sell" <>
> > You didn't supply a MyTagLibrary patch.
> duh. attached now


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


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

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.


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.


Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

View raw message