jackrabbit-dev mailing list archives

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

    [ 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

View raw message