jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (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 08:25:13 GMT

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

Felix Meschberger commented on JCR-3489:
----------------------------------------

Speaking of Sling: Our solution based on the Adaptable interface with the ValueMap is only
a secondary benefit of the Resource API we did to abstract the complex JCR API with checked
exceptions into a simpler, easier to use API which also allows for much simpler and easier
extension by other implementations.

I seriously doubt our Sling implementation will be changed to use this new functionality because
our implementation exists and is proven and is embedded in a larger context (Adaptable with
AdapterFactory).
                
> 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