[
https://issues.apache.org/jira/browse/SLING-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590346#action_12590346
]
Felix Meschberger commented on SLING-386:
-----------------------------------------
Thanks for this information. Let me comment on it ;-)
First of all, I assume you are talking about the nameHint property and not the
name property. Because the value of the name property should be taken as is for
the node name and generate a failure if the name is invalid.
Second, considering john.doe is the value of the nameHint, the behaviour is
almost correct. Except that the xyz_conversion2 is incorrect by the
SlingPostProcessor constructor: This one just cuts off at the dot assuming the
name is john and the extension is doe. That is, the SlingPostProcessour should
probably at least check whether there is a node called john.doe before cutting
off. I consider this a bug in the SlingPostProcessor.
Third, the second use case of John_Doe will never be fixed inside Sling: You
nameHint a name, which is modified but assume the name is not changed. This is
your bug, not Sling's. Sorry.
Other than that, this all still remains a user error: you should take the path
returned from the creation step for further operations, no matter what. Unless,
of course, you use the name property to force (or fail) an exact name.
> rules for creating node names should be uniform
> -----------------------------------------------
>
> Key: SLING-386
> URL: https://issues.apache.org/jira/browse/SLING-386
> Project: Sling
> Issue Type: Improvement
> Reporter: Michael Marth
>
> I have an issue when nodes are created through a form post: consider that I
> have a weird string xyz that is not fit as a JCR node name, e.g. because it
> contains umlauts or slashes or so.
> If I do a post to /content/mynode/*
> and give this parameter
> name=xyz
> this is used as a name hint and xyz is converted something sane (let's call
> it xyy_conversion1)
> In the next step I want to post to /content/mynode/xyz/*
> in order to create a child node of xyz
> It seems that in these two cases xyz is converted differently. Thus, in my
> example above the second post would not create a child node of the first one,
> but rather something like:
> -content
> |-mynode
> |- xyy_conversion1
> |- xyz_conversion_2
> |- node_from_second_post
> the conversation algorithms should be the same in both cases
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
