[
https://issues.apache.org/jira/browse/JCR-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536560#comment-13536560
]
Simone Tripodi commented on JCR-3489:
-------------------------------------
there's a _huge_ difference between hardcoded methods name (which only support
default JCR types) Vs. a unique anonym access that let retrieving the value
independently by the type, which is extensible to unsupported types.
About the method chaining, that make the sample looking more complex to you: I
personally consider fluent interfaces a more intuitive way of designing APIs
against a single method that takes a sequence of arguments - but that's
arguable and I'll keep that discussion outside this thread.
Type conversion, that is not "just" custom object (de)serialization, is a
problem that, since our fellows at [Apache Sling|http://s.apache.org/nf] or our
colleagues at
[Adobe|http://dev.day.com/docs/en/cq/current/javadoc/com/day/cq/commons/inherit/HierarchyNodeInheritanceValueMap.html]
and even our cousins at [Hippo|http://s.apache.org/1cv] had the need to
implement, probably shows a corner case not covered by JCR APIs but that is
required by applications developed on top of JCR.
Implementing that layer - please note that I just added stuff in the codebase,
I didn't modify any existing class - probably would help our mates developing
stuff on top of Jackrabbit.
> 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
