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-184) rework resource name and display name handling in jcr-server
Date Mon, 12 Sep 2005 14:44:31 GMT
    [ 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/jackrabbit-dev@incubator.apache.org/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


Mime
View raw message