cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guido Casper" <gcas...@s-und-n.de>
Subject Re: SourcepropWritingTransformer
Date Tue, 26 Aug 2003 13:32:17 GMT
Gianugo Rabellino wrote:
> I'm about to tackle WebDAV properties handling, and I was happy to
> find that Guido has already provided something. :-)
>
> I am however a bit uncomfortable with the current implementation and
I
> wanted to see if it's just me not having the correct approach.

I'm uncomfortable with the current approach as well (it's work in
progress :-). That is primarily due to the current design and
implementation of (the seemingly unfinished) SourceProperty class.
Changing this was next on my list (as was discussing
SourcepropsWritingTransformer's input XML :-).

I'm however cautious about breaking SourceDescriptionGenerator, more
so that I found that the slide block isn't marked unstable (Is it too
late to change this?).

>
> A source property (both in webdav sense and in the  SourceProperty
> implementation) is made of three part: a local name (String), a
> namespace (String) and a value (DOM Element). It's worth noticing
that
> the property value is actually the *holder element* plus it's value
> (that is a text node - in case of a string value - or other
Elements),
> so that effectively you get, in case of webdav,
>
> <getcontenttype xmlns="DAV:">text/xml</getcontenttype>
>
> a property name of "getcontenttype, a namespace of "DAV:" and a
value
> of (xml-ized)
> <getcontenttype xmlns="DAV:">text/xml</getcontenttype>. User space
> tools will then give you a value of "text/xml", but this is a
> different issue.
>
> All this said, I fail to understand why this transformer is somehow
> reinveinting XML by using this syntax:
>
> <source:prop name="author" namespace="meta">me</source:prop>

I felt like seperating the property namespace from the XML namespaces
was a good idea, since it would be an easy way to deal with
InspectableSource implementations that don't deal with namespaced
properties. On a second thought an alternative would be to have only
one <source:prop> element and have all immediate children be the
properties.

A value of a property however doesn't necessarily has to be XML.
Especially if you think of other Sources besides WebDAVSource.

>
> which forces, besides, to use a very risky solution to rebuild the
> property:
>
>    String pre = "<"+name+" xmlns="+quote+namespace+quote+">";
>    String post = "</"+name+">";
>    String xml = pre+value+post;
>    StringReader reader = new StringReader(xml);
>    Document doc = parser.parseDocument(new InputSource(reader));
>    SourceProperty property = new
>    SourceProperty(doc.getDocumentElement());
> ((InspectableSource)source).setSourceProperty(property);
>
> One of my biggest no-no is not to use string manipulation to build
> XML: this algo would fail in case the element has any XML reserver
> characters

Yes, I know. See above.
However I would prefer to defer the XML handling of property _values_
to the WebDAVSource and have the SourceProperty class be neutral to
XML.

> or is an XML property value with nested elements.
>
> What about using good 'ole XML instead? I'm considering something
> like:
>
>    <source:props>
>       <myns:author xmlns:myns="meta">me</myns:author>
>    </source:props>
>
> This would allow using standard Transformer tools (startRecording()
> instead than startTextRecording()) to set the properties later. It
> would
> be much safer and a good bit more XMLish (and WebDAVish too). Also,
> this modification could be inserted directly into the
> SourceWritingTransformer without requiring a new transformer just to
> set properties.

It feels a bit like mixing concerns to me (setting properties and
writing content).
Currently the only requirement SourceWritingTransformer has is the
Source to be modifiable. You would need to have a look at SWT's input
XML to know which pseudo protcols can be used with it.

Guido


Mime
View raw message