[ http://issues.apache.org/jira/browse/JCR-184?page=comments#action_12323224 ]
angela commented on JCR-184: ---------------------------- okeeeee... let me summarize (i start to get confused): your basic need is to create resources that have a name (last part of the path) that contains caracters that are marked 'reserved' in the jsr170 specification but are not reserved in an uri. this has been discussed before http://www.mail-archive.com/[email protected]/msg01064.html and tobi suggested to provide a corresponding escaping method in the commons. btw: as far as i know this is part of the jsr170 issues list as well. second you want to have a displayname that is not tied to the items name. from my point of view this is a different story, since the displayname defined by rfc 2518 should be whatever the 'server' considers to be human readable. i decided for 'my' resource in the simple server, that the item name is human readable... but you may change that and make your caldav-resource choose another property as displayname. thus: - i can take care of the issue with the uri - jcrname incompatibility - i would rather leave the displayname story up to you, if you want to change that. please correct me, if i got it wrong. regards angela > 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
