jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2154) Use expanded form for Path.getString()
Date Fri, 19 Jun 2009 11:05:07 GMT

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

View raw message