[
https://issues.apache.org/jira/browse/JCR-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539110
]
angela commented on JCR-1200:
-----------------------------
> In which case I'd prefer the latter in order to avoid confusion with the
> other create methods.
ok. the 'from' is may be not totally accurate either. i liked your 'compute'
but i wasn't too happy with
the default-value... because the default value is something different and it's
already
present in the property definition, isn't it ? there is no need to compute that
one...
is it meant to be used for both retrieved default-values AND autocreated values?
then it would probably be
computeValues.
i guess we should also define the behaviour of the method if the
QPropertyDefinition
does neither define defaultvalues nor is autocreated... throwing?
> allow SPI implementation to compute default values for autocreated properties
> -----------------------------------------------------------------------------
>
> Key: JCR-1200
> URL: https://issues.apache.org/jira/browse/JCR-1200
> Project: Jackrabbit
> Issue Type: Improvement
> Components: SPI
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
>
> Currently, when creating nodes in transient space, JCR2SPI uses hard-wired
> logic trying to populate system generated properties such as jcr:created,
> jcr;uuid and so on.
> This is problematic as
> - it doesn't scale -- it fails for autocreated properties not known to
> JCR2SPI, and
> - the syntax for the defaults may be dependant on the back end, such as legal
> syntax for (UU)IDs.
> Proposal:
> - extend QValueFactory with something like
> QValue computeDefaultValue(QPropertyDefinition)
> - use that in JCR2SPI, getting rid of the currently hard-wired logic.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
