jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Edelson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3489) enhance get/set Property value access, expanding the supported types set
Date Thu, 20 Dec 2012 18:47:13 GMT

    [ https://issues.apache.org/jira/browse/JCR-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537249#comment-13537249
] 

Justin Edelson commented on JCR-3489:
-------------------------------------

To be clear, as long as it is well-tested and documented, I'm certainly not opposed to including
this in jcr-commons. It's just not a fair statement to say that this is "simpler" - it results
in longer call depth, more object instantiations, and (arguably) more developer confusion.

Looking at the patch further, I don't see that it improves array handling. This is IMHO an
incredibly useful feature of ValueMap which should be carried over.

Agree with Alex that this is really a spec issue - calling getProperty() in and of itself
is overkill for most simple retrieval use cases where what you really want is to treat the
node as a type-coercing map (see ValueMap).
                
> enhance get/set Property value access, expanding the supported types set
> ------------------------------------------------------------------------
>
>                 Key: JCR-3489
>                 URL: https://issues.apache.org/jira/browse/JCR-3489
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-jcr-commons
>    Affects Versions: 2.5.2
>            Reporter: Simone Tripodi
>            Priority: Minor
>             Fix For: 2.6
>
>         Attachments: JCR-3489.patch
>
>
> The idea is having a small EDSL that simplifies the access to {{Property}} value, so
rather than coding the following:
> {code}
> Property property = ...;
> boolean oldValue = property.getBoolean();
> boolean newValue = !oldValue;
> property.setValue(newValue);
> {code}
> it could be simplified specifying wich type the users are interested on:
> {code}
> PropertyAccessors propertiesAccessor = ...;
> boolean oldValue = propertiesAccessor.get(property).to(boolean.class);
> boolean newValue = !oldValue;
> propertiesAccessor.set(newValue).to(property);
> {code}
> where {{PropertiesAccessor}} is the delegated to handle right types handling. By default
it supports default {{Property}} value types, but it could be extended.
> It could happen also that users would like to support a larger set of types, maybe performing
conversions to/from default {{Property}} types, so rather than inserting the custom code in
the app when required, they could  use the {{PropertiesAccessor}}; they first need to register
the Accessor implementation to (un)bind the type:
> {code}
> propertiesAccessor.handle(URI.class).with(new PropertyAccessor<URI>() {
>             @Override
>             public void set(URI value, Property target) throws ValueFormatException,
RepositoryException {
>                 // ...
>             }
>             @Override
>             public URI get(Property property) throws ValueFormatException, RepositoryException
{
>                 // TODO ...
>                 return null;
>             }
>         });
> {code}
> so they can use the accessor via the {{PropertiesAccessor}}:
> {code}
> URI oldValue = propertiesAccessor.get(property).to(URI.class);
> URI newValue = URI.create("http://jackrabbit.apache.org/");
> propertiesAccessor.set(newValue).to(property);
> {code}
> Patch coming soon!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message