dynabeans are cool - in fact clazz with it's custom meta-data takes dynabeans a stage further. what would be very cool is support for pluggable introspection meta-data.
- robert
On 14 Sep 2004, at 04:53, Hans Gilde wrote:
I agree about JEXL being an alternative BQL.
But, Beanutils also gives us dynabeans. In theory, dynabeans give us an
implementation for two types of tags: tags that take all their properties
through setXXXX and getXXXX and tags that are more dynamic.
The beanutils package detects dynabeans and handles them just like regular
beans. In theory. Apparently, something about dynabeans didn't work in an
earlier beanutils because jelly doesn't use dynabeans quite right. If it
did, the code would be lots cleaner. I'm actually filing this as an issue in
jira now.
Now, the facts are that a) we don't use dynabeans exactly correctly and b)
we could probably squeeze a little more speed out of dynamic tags if we
directly use a Map of properties rather than dynabeans.
Now to add a twist: beanutils will also query the tag (either dyna or
regular bean) and give you a list of all the bean properties, and hence all
the possible XML attributes, for documentation purposes. This *could* be a
pre-built path to auto-documenting dynamic tag libraries like Swing. The
only part that's not handled by beanutils is the part about attaching a text
description to properties found from each tag.
So... to summarize. We could easily replace beanutils/BQL with JEXL if we're
willing to give up dynabeans. Giving up dynabeans would probably allow for a
fairly small performance increase when compiling all tags and when running
dynamic tags. The question is, what would we use instead of dynabeans?
-----Original Message-----
From: robert burrell donkin [mailto:[EMAIL PROTECTED]
Sent: Monday, September 13, 2004 4:32 PM
To: Jakarta Commons Users List
Subject: Re: Jelly and a new beta release
On 12 Sep 2004, at 21:27, Hans Gilde wrote:
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?
i have no good, clear preferences about implementation...
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.
i thought that would be the case.
(on the subject of nomenclacture, i'd describe both JEXL and beanutils as embedding bean query languages as opposed to beanutils having the BQL.)
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="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.
populate is a specialization aimed at processing HTTP requests. i suspect that james chose this because xml<->object is also text<->object. choosing just one system does have limitations.
you're example is a good illustration of the absence of a general solution. in some cases, a.b would be best interpreted as a bean query language phrase and in other cases, it would be better passed without conversion to the bean. i suspect that one size doesn't fit all and that it might be better for conversions to be specified by each tag library (possible using beanutils as a default). JEXL should provide sufficient query language glue.
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.
i don't think that anyone objects to beanutils tag libs: it's the core embedding that's more arguable.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
