[
https://issues.apache.org/jira/browse/SANDBOX-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13936138#comment-13936138
]
Andre Diermann edited comment on SANDBOX-464 at 3/15/14 11:03 AM:
------------------------------------------------------------------
Hello,
I have one question regarding the public API of BU2. Would it be ok, to add
another method named getSimple(), which returns a BeanAccessor for a simple
property where get() could be used to return a BeanAccessor for property
expressions?
Background:
Currently a BeanAccessor provides:
* get()
* getIndexed()
* getMapped()
...where get() is an equivalent to BU1's getSimple(), see [1].
When get() should, like requested in above's issue description, also deal with
property expressions it would give the API user a better control whether he/she
wants to get only a simple property or he/she want's to resolve a complete
property path. From an implementation point of view this would also help to
keep changes small, because the current get() method would become getSimple()
and the implementation of get would be:
public BeanAccessor<?> get( String propertyName )
{
return PropertyInterpreter.interpret( this, propertyName );
}
For me these are two advantages, a more explicit API usage for the user and a
simple implementation. But since it would affect the public API I want to check
with you guys first.
What do you think?
BR
André
[1]
http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.1/apidocs/index.html
was (Author: andd):
Hello,
I have one question regarding the public API of BU2. Would it be ok, to add
another method named getSimple(), which returns a BeanAccessor for a simple
property where get() could be used to return a BeanAccessor for property
expressions?
Background:
Currently a BeanAccessor provides:
* get()
* getIndexed()
* getMapped()
...where get() is an equivalent to BU1's getSimple(), see [1].
When get() should, like requested in above's issue description, also deal with
property expressions it would give the API user a better control whether he/she
wants to get only a simple property or he/she want's to resolve a complete
property path. From an implementation point of view this would also help to
keep changes small, because the current get() method would become getSimple()
and the implementation of get would be:
public BeanAccessor<?> get( String propertyName )
{
return PropertyInterpreter.interpret( this, propertyName );
}
For me these are two advantages, a more explicit API usage for the user and a
simple implementation. But since it would effect the public API I want to check
with you guys first.
What do you think?
BR
André
[1]
http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.1/apidocs/index.html
> Add support for interpreting property expressions
> -------------------------------------------------
>
> Key: SANDBOX-464
> URL: https://issues.apache.org/jira/browse/SANDBOX-464
> Project: Commons Sandbox
> Issue Type: Task
> Components: BeanUtils2
> Affects Versions: Nightly Builds
> Reporter: Benedikt Ritter
>
> BeanUtils 1 has the functionality to interpret property paths. For example
> the call:
> {code:java}
> BeanUtils.getProperty("adress.street", person);
> {code}
> would first get the address of the given person and then get the street from
> the address and return it. The same is possible for list and mapped
> properties.
> In order to be supplement for BeanUtils1, we need to implement this in
> BeanUtils2.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
