[ http://issues.apache.org/jira/browse/JCR-184?page=comments#action_12330070 ]
angela commented on JCR-184: ---------------------------- dealing with the encoding made it clear to me, that its wrong to use dav-resourcepath and itempath exchangeably. this led to some minor modifications that i would like to be commited. you could then introduce your translation as a first workaround. > it may well be the case that this is an issue that needs to be discussed for > jcr 2.0. a while ago i talked to peeter regarding this and he promised to put this on the issue list 2.0. i think the limitation specially for ' and " was introduced because of xml concerns but then the list is not complete. there are other characters that need encoding when building the doc-view... possibly a mistake in the spec... regards angela ps: the 'translation utility' would have gone to the Text (outside webdav). but i could not think of a way to make it unambigous, in order to properly deal with itemnames/path that may be created from encoding-aware and non-aware applications. if you have a solution please let me know. > Simple Webdav: jcr-encoding for resource names contain invalid characters. > -------------------------------------------------------------------------- > > Key: JCR-184 > URL: http://issues.apache.org/jira/browse/JCR-184 > Project: Jackrabbit > Type: Improvement > Reporter: Brian Moseley > Assignee: angela > Priority: Minor > > jcr-server is a bit problematic in the way it treats the display name of a > webdav resource. specifically it forces the display name to be the same as > the name of the resource itself, rather than an arbitrary textual description > of the resource. this is an acceptable default value for a resource's display > name, but a webdav client should be able to change the display name at any > point after creation of the resource. > rfc 2518 says: > 13.2 displayname Property > Name: displayname > Namespace: DAV: > Purpose: Provides a name for the resource that is suitable for > presentation to a user. > Description: The displayname property should be defined on all DAV > compliant resources. If present, the property contains a description > of the resource that is suitable for presentation to a user. > <!ELEMENT displayname (#PCDATA) > > i realize that the goal of the simple webdav server is to support > nt:collection and nt:file, which don't allow extra properties. that's fine; i > have defined my own dav:collection and dav:resource node types on which i can > add a dav:displayname property. i can then override > DavResourceImpl.getDisplayName() to return the value of that property. > the problem is that DavResourceImpl.getDisplayName() as already implemented > has a couple of other purposes - calculating the resource name for a node > that is about to be created and returning the resource name from an existing > node. > furthermore, both resource and display names could potentially contain > characters that are illegal in jcr names. we've talked in the past about > encoding these strings in order to use them as jcr names. this encoding would > be necessary for the resource name (which is used as the node's name) but not > for the display name (which would be persisted as a property value). > i propose the following DavResourceImpl methods: > getResourceName() - returns the (unencoded) name of the resource, which is > either the name of the resource's node (if the resource exists) or the final > segment of the resource's uri path > getDisplayName() - returns the value of the resource's DAV:displayname > property (if both the resource and property exist) or the string returned > from getResourceName > DavResourceImpl could simply always `return getResourceName()' as its > implementation of getDisplayName(). subclasses would be free to override it > to retrieve the display name from a jcr property. > DavResourceImpl would also take care of encoding the resource name before > creating the new node and decoding the resource name before returning it from > getResourceName(). > thoughts? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
