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
