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 19:00:25 GMT
From: "Christian Sell" <>
> I've got to have a final stab at this (no, it isn't that I always have
> to have the last word. Just this time..)


> > (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
> >
> > 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
> > namespaces.
> I think mixing namespaces is what Jelly is all about, in a sense.. Whats
> bad about the beandef?

Nothing at all.

> In fact a useBean would do as well, wouldn't it?
> <useBean xmlns="jelly:core" xmlns:bean="jelly:bean" var="c1"
> class="org.dada.Customer">
>     <bean:order>
>          <bean:product/>
>      </bean:order>
> </useBean>


The point I was trying to get across with (iii) was that sometimes folks
might want to create a complete beanified library without requiring 2
namespaces (one for the beans and one for the nested properties).

e.g. just for sake of argument, if we were using Jelly to implement the
commons-sql project and to parse its XML language into beans, it'd be nice
to hide the <beandef> and to use a single namespace (or even no namespace).


We're agreeing I think. It just depends on what you need as to what approach
to take. For example I do like being able to use the bean library with
<beandef> or <useBean> as you demonstrate, to construct and configure beans
inside Jelly.

> > 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).
> 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.
> Thats why I like (iii) (that had to be said, of course).

Thats fine.


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

View raw message