[
https://issues.apache.org/jira/browse/SLING-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552731
]
Bertrand Delacretaz commented on SLING-133:
-------------------------------------------
We discussed this on the list, and the consensus seems to be that the resource
type of a Property should be the resource type of the parent node, followed by
the property name with some character filtering to make it suitable as a script
name.
For example, the jcr:data property of an nt:resource node would have a resource
type of "nt:resource/jcr:data" which translates to "nt/resource/jcr/data" as
the script path.
> microsling Resource resolver and default renderers do not support Properties
> ----------------------------------------------------------------------------
>
> Key: SLING-133
> URL: https://issues.apache.org/jira/browse/SLING-133
> Project: Sling
> Issue Type: Improvement
> Components: microsling
> Reporter: Bertrand Delacretaz
> Priority: Minor
>
> Currently, assuming the /content/testing/foo Node exists and has a "text"
> property, requesting /content/testing/foo/text.txt (or any other extension)
> fails with a ClassCastException, as the resolution and rendering chain
> supports Nodes only.
> It should be fairly easy to use a JcrPropertyResource when the
> MicroslingResourceResolver finds an Item that is a Property, and let the
> default renderers handle it.
> One use case, is, when working with client-side forms, to fill a <textarea>,
> for example, with the value of a property, based on a relative URL.
> I don't think we need to handle POSTs to Properties for now, but GETs are
> useful in the above case, and for testing as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
