You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Tobias Bocanegra (JIRA)" <ji...@apache.org> on 2009/06/17 13:56:07 UTC
[jira] Created: (JCR-2154) Use expanded form for Path.getString()
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.
[jira] Commented: (JCR-2154) Use expanded form for Path.getString()
Posted by "angela (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-2154) Use expanded form for Path.getString()
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720643#action_12720643 ]
angela commented on JCR-2154:
-----------------------------
i don't have any particular feelings regarding the nature of the path delimiter used for the Path object.
but instead of changing the value of Path#DELIMITER, i would probably rather mark i deprecated and introduce
a separate delimiter constant indicating that it is valid as of version 2.0....
regarding the example:
wouldn't the result rather be
{}/{http://www.apache.org/jackrabbit/test}testPath
?
Section 2.3.5.1 defines the expanded name to be
ExpandedName ::= '{' Namespace '}' LocalName
which from my understanding would result in "{}" for the root node's name, wouldn't it?
> if this is too much of a change
i don't know all the details by heart... but i'd expect that the changes was limited to Path (see above) and the PathFactory implementation (-s if there are custom path and factory implementations outside of jackrabbit).
> 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.
[jira] Updated: (JCR-2154) Use expanded form for Path.getString()
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-2154:
-------------------------------
Fix Version/s: (was: 2.0.0)
> 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
>
> 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.
[jira] Commented: (JCR-2154) Use expanded form for Path.getString()
Posted by "angela (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JCR-2154) Use expanded form for Path.getString()
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721782#action_12721782 ]
Tobias Bocanegra 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.
> 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.
[jira] Commented: (JCR-2154) Use expanded form for Path.getString()
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720648#action_12720648 ]
Tobias Bocanegra commented on JCR-2154:
---------------------------------------
> regarding the example:
> wouldn't the result rather be
> {}/{http://www.apache.org/jackrabbit/test}testPath
no, since it's an absolute path:
Path ::= AbsolutePath | RelativePath
AbsolutePath ::= '/' [RelativePath] | '[' Identifier ']'
RelativePath ::= [RelativePath '/'] PathSegment ['/']
PathSegment ::= ExpandedName [Index] | QualifiedName [Index] | SelfOrParent
At least could we add the getExpandedString() method and make the PathFormat aware of it?
> 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.