commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: Jelly and a new beta release
Date Thu, 16 Sep 2004 21:50:57 GMT
if necessary, it should be easy to retrofit dynabean support to 
whatever jelly ends up using.

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:robertburrelldonkin@blueyonder.co.uk]
> 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: 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


Mime
View raw message