cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: SourcepropWritingTransformer
Date Tue, 26 Aug 2003 14:00:31 GMT
Guido Casper wrote:
>>I am however a bit uncomfortable with the current implementation and
> 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 sure about that, and, just in case, please note that I didn't want 
to sound harsh, I was just trying to be constructive. :-)

> 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?).

I guess we should ask Stephen about it, but I'd be +1, since Slide 
itself is unstable.

> 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. 

I don't think that, even after the possible refactoring of 
InspectableSource, all SourceProperties should be namespaced. It makes 
very little sense today not to use namespace for properties: in case 
there is no need for a namespace it would be pretty easy to add a 
convenience one and preserve both ease of use and rich properties.

> On a second thought an alternative would be to have only
> one <source:prop> element and have all immediate children be the
> properties.

Do we have a deal then with something like the following?

<source:props> <!-- plural is better IMO -->
   <my:author>Me, Myself and I</my:author>

Implementing this scenario should be fairly easy. startRecording() on 
source:props startElement(), endRecording() on endElement(); then get 
the resulting DocumentFragment and for each child set a SourceProperty 
using that Element. How does it sound?

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

This is, however, the case of the current SourceProperty, a contract 
that, as of now, we might not want to break. Actually it would be pretty 
simple to refactor it in a more generic way, passing from an Element to 
a Node which might be a text node in case of simple string properties. 
But again, this is not the case for now.

> 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.

The problem is that it's not XML neutral already. :-/ Value is an 
Element as of now.

> It feels a bit like mixing concerns to me (setting properties and
> writing content).

I don't think so. It makes sense for metadata to be written together 
with data (and being manipulated separately if that's the case), what's 
wring with it?

> 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.

It can easily remain so. Just if( source instanceof InspectableSource) 
and you can have a perfectly backward compatible SWT...


Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance -
     (Now blogging at:

View raw message