[
https://issues.apache.org/jira/browse/SLING-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587062#action_12587062
]
Felix Meschberger commented on SLING-367:
-----------------------------------------
Please review the respective discussion at [1]. The problem is the collision of
the prefix used for properties and for parameters. At the moment we have -
AFAIK - three well-known properties with the prefix sling: If we change
sling:post: to sling: we would have to filter for these property names and
would have issues, if another property would be added. (BTW: Storing the
sling:resourceType property is an intention not a side-effect).
On the other hand we could of course place all the command names in a
collection and for each parameter check whether it is part of that collection
and ignore it then. The only problem is, that we then prevent using names like
sling:remove. Agreed, I don't see a real use case - except perhaps storing a
bunch of batch operations in the repository ?? - but I just don't want to
prevent this.
Having the command prefix be sling:post: we definitely prevent this for being
used as property names, as names with two colons would anyway be illegal.
For this reason, I am against this change. All the more, that we have SLING-258
which should create constants for these command names for easy use.
[1] http://markmail.org/message/fgyux3tyo2cvipun
> change sling:post: to sling: for "command" prefixes in form names
> -----------------------------------------------------------------
>
> Key: SLING-367
> URL: https://issues.apache.org/jira/browse/SLING-367
> Project: Sling
> Issue Type: Bug
> Components: ujax
> Reporter: David Nuescheler
>
> I think it is fair to also prefix the form elements that express certain
> "commands"
> with "sling:" since they are sling related.
> i see it more as a side effect that the "sling:resourceType" also gets
> persisted.
> generally, i think everything that has something to with "sling" should be
> prefixed
> with "sling".
> I think we need to make sure that we don't complicate the most simple cases
> just
> to a avoid possible collisions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
