From: "Christian Sell" <[EMAIL PROTECTED]> > 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 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
