Return-Path: <james_strachan@yahoo.co.uk>
Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list commons-user@jakarta.apache.org
Received: (qmail 21763 invoked by uid 98); 21 Jan 2003 19:02:38 -0000
X-Antivirus: nagoya (v4218 created Aug 14 2002)
Received: (qmail 21736 invoked from network); 21 Jan 2003 19:02:36 -0000
Received: from unknown (HELO apache.org) (63.251.56.142)
  by nagoya.betaversion.org with SMTP; 21 Jan 2003 19:02:36 -0000
Received: (qmail 94241 invoked by uid 500); 21 Jan 2003 19:01:10 -0000
Received: (qmail 94233 invoked from network); 21 Jan 2003 19:01:10 -0000
Received: from smtp015.mail.yahoo.com (216.136.173.59)
  by 208.185.179.12.available.above.net with SMTP; 21 Jan 2003 19:01:10 -0000
Received: from pc-80-193-217-22-hw.blueyonder.co.uk (HELO lndevjs)
 (james?strachan@80.193.217.22 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 21 Jan 2003 19:01:14 -0000
Message-ID: <07b001c2c17f$5c324180$9865fea9@spiritsoft.com>
From: "James Strachan" <james_strachan@yahoo.co.uk>
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
References: <D44A54C298394F4E967EC8538B1E00F1D2BB9C@lgchexch002.lgc.com>
 <3E2C8082.4080206@netcologne.de>
 <006001c2c126$63e49d00$9865fea9@spiritsoft.com>
 <3E2D39F3.5040003@netcologne.de>
 <02e901c2c149$cc9586c0$9865fea9@spiritsoft.com>
 <3E2D575A.9050902@netcologne.de>
 <04b001c2c160$cf408b10$9865fea9@spiritsoft.com>
 <3E2D6D0A.5090401@netcologne.de>
 <056201c2c166$881779a0$9865fea9@spiritsoft.com>
 <3E2D722E.7030804@netcologne.de>
 <05ed01c2c16a$f3ce4170$9865fea9@spiritsoft.com>
 <3E2D95D3.4090002@netcologne.de>
Subject: Re: [jelly]  taglib implementation questions
Date: Tue, 21 Jan 2003 19:00:25 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Rating: 208.185.179.12.available.above.net 1.6.2 0/1000/N

From: "Christian Sell" <christian.sell@netcologne.de>
> 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
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.
>
> 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>

Absolutely.

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

e.g.

http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/sql/src/test-input
/datamodel.xml?rev=HEAD

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.

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