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] Tag attributes corresponding to arrays
Date Thu, 06 May 2004 21:06:26 GMT
On 6 May 2004, at 18:35, Geoffrey Arnold wrote:

> Hi Robert.
>
>> i think that you might be able to achieve the same result by  
>> registering a custom convertor. this is currently a little icky to do 
>>  but it would probably be possible to add some (probably core) tags 
>> that  would allow the conversions to be customized. i'm not sure 
>> whether  that'd be a good idea or not.
>
> Unfortunately, I think that this behavior is hardcoded in 
> BeanUtils.setProperty() method at lines 979-981 (of release 1.6.1).  
> Basically the code stuffs the value into a single element array 
> _before_ calling the CovertUtils.convert() method.

fair 'nuff

>> in some ways, using the specialized http copy makes some sense 
>> because  jelly's stringy like html but the implementation is less 
>> sophisticated.  would altering one to the other cause loads of stuff 
>> to break?
>
> I don't follow the first comment.

i meant http copying involves strings-to-beans (rather than general 
bean-to-bean) so it sort of makes sense from that perspective. not sure 
what other effects moving from one to the other would have.

maybe it'd be possible to add a namespaced attribute 
(?jelly:conversion='classic'?) which could be inherited and so allow 
the user to control the tag <-> bean mapping.

> As for breaking existing code, I was afraid of this also, but after 
> skimming through the code (and running the unit tests :) ), it appears 
> that the changes do not adversely affect any of the Jelly codebase.  I 
> believe that these changes would only affect existing users who have 
> modified their "setTheArray(String[])" methods to parse the first 
> element of the array to convert it to the proper array (which would be 
> counter-intuitive).

can anyone else think of anything that this change is likely to break?

- robert


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