[
https://issues.apache.org/jira/browse/JCR-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi updated JCR-3489:
--------------------------------
Description:
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!
was:
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}
> 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
>
>
> 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
