[ http://issues.apache.org/jira/browse/JCR-184?page=comments#action_12324422 ]
angela commented on JCR-184: ---------------------------- you're welcome! (and so is your feedback). api changes are basically ok. i once that the 'getDisplayName' in the api but later on i wanted to get rid of those methods that are shortcuts only for getProperty. yes, there are still a few left, that i consider to be of greater importance at that time :). please keep posting bugs and enhancement request. i'm going to take care of the escaping in the meantime. > rework resource name and display name handling in jcr-server > ------------------------------------------------------------ > > 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
