[
https://issues.apache.org/jira/browse/SLING-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-7959:
-----------------------------------
Comment: was deleted
(was: The first feature is not 100% compatible with the current
{{ContentHandler}} interface as that only allows to create new resources (but
not to enrich already existing resources with additional properties). Also the
parser for that would need to somehow get the information which resource name
the current context resource has.
[~sseif...@pro-vision.de] How do you think about this? What about passing the
context resource path to the parsers via {{ContentParserFactory}}. Then the
{{JcrXmlContentParser}} could call its {{ContentHandler}} for this given
resource path and extend the properties? To make that backwards compatible we
could add a new overloaded method {{ContentParser create(ContentType type,
String contextResourcePath)}}. Alternatively this context path could be passed
via the {{ParserOptions}}.)
> ContentParser: Complete support for Extended DocView
> ----------------------------------------------------
>
> Key: SLING-7959
> URL: https://issues.apache.org/jira/browse/SLING-7959
> Project: Sling
> Issue Type: Bug
> Components: JCR
> Affects Versions: JCR Content Parser 1.2.4
> Reporter: Konrad Windszus
> Priority: Major
>
> The following features from either standard JCR 2.0 or extended docview
> ([http://jackrabbit.apache.org/filevault/docview.html]) are not properly
> supported yet:
> # jcr:root notation (then the name is basically coming from the file name)
> # same-name-siblings with a format like {{<nodename>[<index>]}} (the index
> should then be stripped out, as at least Sling Resource Providers in general
> don't have a limitation on same name siblings).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
