[
https://issues.apache.org/jira/browse/JCR-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721819#action_12721819
]
angela commented on JCR-2154:
-----------------------------
> i don't think it's wrong to internally store a path (or name) in a
> standardized way,
> instead of some funny tab separated manner.
nor do i.... :)
i don't reject to your first proposal regarding changing the internal
representation of a path.
i just don't see any use of the getExpandedString() method and i interpreted
your 'at least' comment as some sort of doubt regarding changing the internal
representation...
> Use expanded form for Path.getString()
> --------------------------------------
>
> Key: JCR-2154
> URL: https://issues.apache.org/jira/browse/JCR-2154
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-spi
> Affects Versions: 2.0-alpha1
> Reporter: Tobias Bocanegra
> Fix For: 2.0.0
>
>
> Currently the internal string representation of a path consists of extended
> path segments which are tab (\t) delimited.
> since JCR2.0, JCR input names can also be specified in an expanded form (see
> JCR 2.0, 3.2.5.1).
> i think it would make sense to use the expanded form also for internal string
> representation of paths, which is defined by the spec, is more natural and
> more readable
> current:
> {} {http://www.apache.org/jackrabbit/test}testPath
> suggested:
> /{http://www.apache.org/jackrabbit/test}testPath
> of course, the PathFactory needs to be backward compatible, since the path
> property values are persisted in the current toString() representation.
> if this is too much of a change, or if there are any valid reasons why the
> tab-delimited form is needed, we should at least add a new method to Path:
> String getExpandedString()
> that returns the expanded form representation of the path.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
