[
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
