jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek (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 17:23:12 GMT

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

Alexander Klimetschek commented on JCR-3489:

Agree with Felix and Julian. Apart from hiding the more intrusive exceptions in JCR, the ValueMap
in sling mostly solves the very common default value case (e.g. properties.get("foo", "defaultValue"))
or the give me a "null" value in case the property does not exist (properties.get("foo", String.class)),
again instead of exceptions or hasProperty() overhead.

Adapting properties to some complex types is not a common use case...

In any way, this might be some fuel for [JCR 2.1 (JSR 233)|http://jcp.org/en/jsr/detail?id=333],
which has improved usability and scriptability of the API as a goal. But don't know what the
latest status of the spec is - afaik quite some inactivity over the last year.
> 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

View raw message