You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ricky Panaglucci <hi...@yahoo.co.uk> on 2003/10/22 00:27:57 UTC

[digester] populating beans fixed to BeanUtils?

hello,

is it by design, that SetPropertyRule and
SetPropertiesRule use BeanUtils.populate()?
it would be usefull to use other binders as well.

ricardo

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk

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


Re: [digester] populating beans fixed to BeanUtils?

Posted by robert burrell donkin <ro...@AlmostHuman.com>.
On Wednesday, October 29, 2003, at 09:21 AM, Henning P. Schmiedehausen 
wrote:

> robert burrell donkin <ro...@blueyonder.co.uk> writes:
>
> [about beanutils]
>
> One of the beauties of digster + beanutils is, that you can use this:
>
>       <pattern value="signal">
>         <set-properties-rule>
>           <alias attr-name="attrA"    prop-name="attrA" />
>           <alias attr-name="attrB"    prop-name="foo.attrB" />
>         </set-properties-rule>
>       </pattern>
>
> and get the second property setter deferenced to getFoo().setAttrB()
>
> which I wouldn't want to miss for anything in the world. So please keep
> Beanutils. :-)

one of the reasons why i've been thinking of factoring out the interface 
is that some of the more advanced stuff that beanutils can now do (or will 
be able to do in the future) means passing in a configured bean (rather 
than using the class methods). but don't worry, backwards compatibility 
will be retained.

- robert


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


Re: [digester] populating beans fixed to BeanUtils?

Posted by Ricky Panaglucci <hi...@yahoo.co.uk>.
> One of the beauties of digster + beanutils is, that
> you can use this:
> 
>       <pattern value="signal">
>         <set-properties-rule>
>           <alias attr-name="attrA"   
> prop-name="attrA" />
>           <alias attr-name="attrB"   
> prop-name="foo.attrB" />
>         </set-properties-rule>
>       </pattern>
> 
> and get the second property setter deferenced to
> getFoo().setAttrB()
> 
> which I wouldn't want to miss for anything in the
> world. So please keep
> Beanutils. :-)
> 

henning,
probably just miscommunication, it was not my
intention to rip out the heart of digester ;)
only that it should be possible to achive the 
behaviour you described by other means than BeanUtils 
(which could be used by default)

ricardo


________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk

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


Re: [digester] populating beans fixed to BeanUtils?

Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
robert burrell donkin <ro...@blueyonder.co.uk> writes:

[about beanutils]

One of the beauties of digster + beanutils is, that you can use this:

      <pattern value="signal">
        <set-properties-rule>
          <alias attr-name="attrA"    prop-name="attrA" />
          <alias attr-name="attrB"    prop-name="foo.attrB" />
        </set-properties-rule>
      </pattern>

and get the second property setter deferenced to getFoo().setAttrB()

which I wouldn't want to miss for anything in the world. So please keep
Beanutils. :-)

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!" 
      -- AOL CD when played backwards  (User Friendly - 200-10-15)

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


Re: [digester] populating beans fixed to BeanUtils?

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, October 30, 2003, at 12:50 AM, Craig R. McClanahan wrote:
> Ricky Panaglucci wrote:

<snip>

>> imo it would be appreciated by many users (at least
>> in the longterm) if an interface and/or factory is
>> provided which, call it a "use case", allows for custom DynaBean-like 
>> behaviour.
>>
>> regards,
>> ricardo
>>
>> ps. do you mean sending example implementation?
>>
>>
>>
> This would require a Digester private API for defining what kinds of 
> property setting could be done, and seems like a rational enhancement for 
> those who want to specialize.

yep.

i'm sort of thinking forward to when we get time to complete the 
beanutification of beanutils (i know that it's been a long time coming). 
it would be useful to be able to easily create subclasses that took 
particular beanutilbean instances. this would allow (say) custom 
converters to be registered at different patterns.

> But it seems a heck of a lot easier to just define some Rule 
> implementations that do what *you* want.  There's no requirement to use 
> the standard Rule implementations that are provided.

+1

- robert


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


Re: [digester] populating beans fixed to BeanUtils?

Posted by "Craig R. McClanahan" <cr...@apache.org>.
Ricky Panaglucci wrote:

>robert,
>i like beanutils very much.
>but the assumption being made is, that the target 
>object either implements set/get according to spec or
>is an instance of DynaBean.
>
>  
>
Note that "the spec" you are talking about is the JavaBeans spec, which 
allows you to define BeanInfo classes for your beans if they don't use 
the standard get/set naming pattern for properties.

>imo it would be appreciated by many users (at least
>in the longterm) if an interface and/or factory is
>provided which, call it a "use case", allows for 
>custom DynaBean-like behaviour.
>
>regards,
>ricardo
>
>ps. do you mean sending example implementation?
>
>  
>

This would require a Digester private API for defining what kinds of 
property setting could be done, and seems like a rational enhancement 
for those who want to specialize.  But it seems a heck of a lot easier 
to just define some Rule implementations that do what *you* want.  
There's no requirement to use the standard Rule implementations that are 
provided.

Craig


> --- robert burrell donkin
><ro...@blueyonder.co.uk> wrote: > hi
>ricky
>  
>
>>beanutils adds quite a few powerful features which
>>(seems to me to) 
>>justify these dependencies.
>>
>>there are some good reasons why it might be useful
>>to abstract the actual 
>>population from the mechanism used to perform the
>>population. i'm not sure 
>>whether the best way to do this would be through
>>delegation to a strategy 
>>interface or through inheritance. i'd be interested
>>to here other people's 
>>views on this.
>>
>>i don't seem to get as much coding time as i'd like
>>these days so i 
>>probably won't get round to coding this any time
>>soon but patches 
>>(including test cases ;) would be gratefully
>>received.
>>    
>>
>
>
>
>________________________________________________________________________
>Want to chat instantly with your online friends?  Get the FREE Yahoo!
>Messenger http://mail.messenger.yahoo.co.uk
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>  
>



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


Re: [digester] populating beans fixed to BeanUtils?

Posted by Ricky Panaglucci <hi...@yahoo.co.uk>.
robert,
i like beanutils very much.
but the assumption being made is, that the target 
object either implements set/get according to spec or
is an instance of DynaBean.

imo it would be appreciated by many users (at least
in the longterm) if an interface and/or factory is
provided which, call it a "use case", allows for 
custom DynaBean-like behaviour.

regards,
ricardo

ps. do you mean sending example implementation?

 --- robert burrell donkin
<ro...@blueyonder.co.uk> wrote: > hi
ricky
> 
> beanutils adds quite a few powerful features which
> (seems to me to) 
> justify these dependencies.
> 
> there are some good reasons why it might be useful
> to abstract the actual 
> population from the mechanism used to perform the
> population. i'm not sure 
> whether the best way to do this would be through
> delegation to a strategy 
> interface or through inheritance. i'd be interested
> to here other people's 
> views on this.
> 
> i don't seem to get as much coding time as i'd like
> these days so i 
> probably won't get round to coding this any time
> soon but patches 
> (including test cases ;) would be gratefully
> received.



________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk

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


Re: [digester] populating beans fixed to BeanUtils?

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
hi ricky

beanutils adds quite a few powerful features which (seems to me to) 
justify these dependencies.

there are some good reasons why it might be useful to abstract the actual 
population from the mechanism used to perform the population. i'm not sure 
whether the best way to do this would be through delegation to a strategy 
interface or through inheritance. i'd be interested to here other people's 
views on this.

i don't seem to get as much coding time as i'd like these days so i 
probably won't get round to coding this any time soon but patches 
(including test cases ;) would be gratefully received.

- robert

On Friday, October 24, 2003, at 08:09 AM, Ricky Panaglucci wrote:

> simon,
> BeanUtils does the actual setting of properties.
> there are many other "JavaSpec conforming" utilities.
>
> (i use castor for introspection and generating
> relevant information)
>
> you are right, i can always use new rules...
>
> i still feel the dependency on BeanUtils in the
> populate() and setProperty() cases is too much - while
>
> ok in CallMethodRule etc
>
>
> ricardo
>
>  --- Simon Kitching <si...@ecnetwork.co.nz> wrote: >
> On Wed, 2003-10-22 at 11:27, Ricky Panaglucci wrote:
>>> hello,
>>>
>>> is it by design, that SetPropertyRule and
>>> SetPropertiesRule use BeanUtils.populate()?
>>> it would be usefull to use other binders as well.
>>
>> Well, the term "property" in the name of these rules
>> is intended to
>> refer to the definition of a JavaBean property as
>> per the official
>> JavaBean specification.
>>
>> The BeanUtils library implements that specification,
>> so there doesn't
>> seem to be much need for allowing the user to
>> configure alternate
>> implementations.
>>
>> If you do wish to map xml attributes to class
>> methods in a way other
>> than the JavaBean spec defines, you can always
>> create your own rule,
>> like
>>   SetRicardoPropertyRule(...)
>> which uses some other algorithm for determining
>> which method to invoke
>> on an object given an xml attribute or element name.
>>
>> What "other binder" do you have in mind?
>>
>>
>> Regards,
>>
>> Simon
>>
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> commons-dev-help@jakarta.apache.org
>>
>
> ________________________________________________________________________
> Want to chat instantly with your online friends?  Get the FREE Yahoo!
> Messenger http://mail.messenger.yahoo.co.uk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


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


Re: [digester] populating beans fixed to BeanUtils?

Posted by Ricky Panaglucci <hi...@yahoo.co.uk>.
simon,
BeanUtils does the actual setting of properties.
there are many other "JavaSpec conforming" utilities.

(i use castor for introspection and generating
relevant information)

you are right, i can always use new rules...

i still feel the dependency on BeanUtils in the
populate() and setProperty() cases is too much - while

ok in CallMethodRule etc


ricardo

 --- Simon Kitching <si...@ecnetwork.co.nz> wrote: >
On Wed, 2003-10-22 at 11:27, Ricky Panaglucci wrote:
> > hello,
> > 
> > is it by design, that SetPropertyRule and
> > SetPropertiesRule use BeanUtils.populate()?
> > it would be usefull to use other binders as well.
> 
> Well, the term "property" in the name of these rules
> is intended to
> refer to the definition of a JavaBean property as
> per the official
> JavaBean specification.
> 
> The BeanUtils library implements that specification,
> so there doesn't
> seem to be much need for allowing the user to
> configure alternate
> implementations.
> 
> If you do wish to map xml attributes to class
> methods in a way other
> than the JavaBean spec defines, you can always
> create your own rule,
> like
>   SetRicardoPropertyRule(...)
> which uses some other algorithm for determining
> which method to invoke
> on an object given an xml attribute or element name.
> 
> What "other binder" do you have in mind?
> 
> 
> Regards,
> 
> Simon
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>  

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk

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


Re: [digester] populating beans fixed to BeanUtils?

Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Wed, 2003-10-22 at 11:27, Ricky Panaglucci wrote:
> hello,
> 
> is it by design, that SetPropertyRule and
> SetPropertiesRule use BeanUtils.populate()?
> it would be usefull to use other binders as well.

Well, the term "property" in the name of these rules is intended to
refer to the definition of a JavaBean property as per the official
JavaBean specification.

The BeanUtils library implements that specification, so there doesn't
seem to be much need for allowing the user to configure alternate
implementations.

If you do wish to map xml attributes to class methods in a way other
than the JavaBean spec defines, you can always create your own rule,
like
  SetRicardoPropertyRule(...)
which uses some other algorithm for determining which method to invoke
on an object given an xml attribute or element name.

What "other binder" do you have in mind?


Regards,

Simon


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