[ 
https://issues.apache.org/jira/browse/JCR-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721737#action_12721737
 ] 

angela commented on JCR-2154:
-----------------------------

> At least could we add the getExpandedString() method 

hm.... that looks wrong to me. The expanded form is a variant of a JCR name 
string. but Path is an internal
API interface. what is the use of having that method on the internal path 
representation? and who is going to take advantage of it?

> and make the PathFormat aware of it? 

do you mean the PathResolver? the PathParser?
both are already adjusted to deal with the various new JCR path formats present 
with JCR 2.0 including the expanded form and the identifier-based form... (in 
case it doesn't its a bug. but i thought there are tests for that...).

maybe this issue is obsolete?

> 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.

Reply via email to