Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of hgilde-commons@earthlink.net
 designates 207.217.120.18 as permitted sender)
From: "Hans Gilde" <hgilde-commons@earthlink.net>
To: "'Jakarta Commons Users List'" <commons-user@jakarta.apache.org>
Subject: RE: Jelly and a new beta release
Date: Sun, 12 Sep 2004 16:27:52 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <A9525616-04DD-11D9-BAA9-003065DC754C@blueyonder.co.uk>
Thread-Index: AcSY6oEqzQxeoHAXRxa90u7RJwCTqAADp5gQ
Message-Id: <E1C6aww-00022X-00@goose.mail.pas.earthlink.net>

When you say "allowing tag libraries to declare bindings", do you mean =
Java
tag libs declaring Java constructs, Java tag libs declaring XDoclet
constructs or a separate descriptor for each tag lib? Or a combination =
of
the above?

On the bean query language thing:

A construct like ${bean.array[2].property} would use JEXL, which might =
use
BQL for all I know. But Jelly would not use BQL directly in this case.

When converting XML attributes to bean properties, Jelly currently uses
BeanUtils.populate. Now, BeanUtils recommends using copyProperties =
instead
of populate. I was thinking of changing to copyProperties recently, =
until I
noticed a somewhat odd side effect of populate: If you declare an XML
attribute a.b=3D"foo", the string "a.b" will be passed to populate as =
the
property name. populate will use BQL, and this single XML property will
result in bean.getA().setB("foo"). So, in this case, BQL is used. I =
don't
know if an attribute with a "." is legal XML but Xerces 2.2.1 doesn't
complain. I also don't know if we want an XML attribute a.b to resolve =
to
getA().setB() but... it makes the whole thing a little more complicated.

Also, the "set" tag (sets a bean property on a parent bean tag) relies =
on
BeanUtils to resolve the property name and BeanUtils uses BQL, which we
definitely want.

So, in short, Jelly uses BQL in some cases but not in most cases. And it
behaves the same in any case.

Hans

-----Original Message-----
From: robert burrell donkin =
[mailto:robertburrelldonkin@blueyonder.co.uk]=20
Sent: Sunday, September 12, 2004 12:03 PM
To: Jakarta Commons Users List
Subject: Re: Jelly and a new beta release

a few comments (in no particular order)...

allowing tag libraries to declare bindings sounds like the way to go.=20
in addition to the advantages already outlined, it might allow the=20
possibility of generate a concrete binding implementation for a tag=20
library. generated bindings are quicker than dynamic ones that use=20
reflection.

there are two real parts to beanutils: the bean query language and the=20
conversions. i suspect that since jelly has JEXL, it doesn't need to=20
use the beanutils bean query language. does anyone know whether this is=20
correct?

it'd probably be better to factor the bridging conversion code into=20
jelly (rather than beanutils). that way, anyone who wants to create a=20
tag library that uses some custom mechanism can do so more easier. this=20
would allow a jelly specific interface rather than a generic one.

- robert

On 11 Sep 2004, at 01:32, Hans Gilde wrote:

> I like this idea. At the moment, we do have subclass-based attribute
> conversion.
>
> What I really like is the automatic documentation aspect, although the
> declarative part sounds good too.
>
> Whatever the solution, we could provide a Java-only version so that=20
> tags
> don't have to use the declarative syntax if they don't want to. The
> Java-only version would let tags avoid a speed problem with loading=20
> mappers.
>
>
> So, a set of mappers would be needed per tag library (Swing's mappings
> aren't SWT's mappings) and possible per bean class. Mappers would=20
> intercept
> a get/set for a specific bean property name and apply the conversion.
>
> But, it gets more complicated because lots of libraries have methods=20
> like
> setSize(int x, int y), which we want to "convert" from a single XML
> attribute "size".
>
> This sort of fits in with the idea of having an XML "config" file for=20
> every
> tag library.
>
> -----Original Message-----
> From: Paul Libbrecht [mailto:paul@activemath.org]
> Sent: Friday, September 10, 2004 5:14 PM
> To: Jakarta Commons Users List
> Subject: Re: Jelly and a new beta release
>
> The problem with this approach, I think, is that it could be done much
> more declaratively thus providing support for tag-documentation...
>
> Mapping constants to integer could, for example, easily be done such.
>
> The declarative way that I was believing to be good would be to make a
> conversion-context class, presumably in beanutils, which would be a =
set
> of mappers. It could be called for copy (or set)Property just the
> static calls currently except, it could be configurable!
>
> Now, maybe such mappers would actually be slow things to load... I
> don't know...
>
> Instead we have subclass-based attribute-conversion parametrization
> currently as in UseBean, right ?
>
> paul
>
>
> Le 10 sept. 04, =E0 22:59, Hans Gilde a =E9crit :
>
>> This is supported in a generic way by the jelly UseBeanTag and used =
in
>> several places like the Swing tags. The way it's supported may look a
>> little inelegant in the code but I agree that it's certainly not due
>> to some huge deficiency in the BeanUtils.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org