Justin Lipton wrote:
True MVPs could handle the first example easily - it was too simple. As
soon as you start nesting properties it becomes very messy to express
using MVPs e.g.
actually that's not the problem... there is not requirement
to map a DavProperty to a single-value nor a multivalue jcr
property.
currently it works as follows (correct me if i'm wrong):
1) upon PROPPATCH a 'changeList' is generated that contains
the DavProperties to be set and the DavPropertyNames for
the props to be removed.
2) this changeList gets passed to the PropertyHandler.
3) now: the DefaultHandler (not aware of xml-properties)
- takes the String representation of the DavProperty
- writes it to a jcr-property name according to DavProperty.getName
in order to deal with xml-properties we could
a) evaluate the return value of DavProperty.getValue()
b) apply the same logic that is applied when creating
DefaultDavProperty out of the xml (copy from javadoc):
* - empty Element -> <code>null</code> value
* - single Text content -> <code>String</code> value
* - single non-Text content -> Element.getContent(0) is
used as value
* - other: List obtained from Element.getContent() is used
as value
c) for the 3rd and the 4th variant we need to write some
new code for DefaultHandler.
without carefully thinking about it, i'd say that julians
suggestion to create a jcr-node for each of the xml properties
should work.
d) also adjust the exportProperty method in order not only
take jcr-properties into account.
e) make sure, XMLHandler does not equivocally exports the
xml-props during content-export.
regards
angela
