cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: DOM Protocol, Was: Revised ResourceLoadAction posted...
Date Tue, 18 Nov 2003 14:35:23 GMT
Daniel Fagerstrom wrote:

> Vadim Gritsenko wrote:
>> Sylvain Wallez wrote:
>>> Vadim Gritsenko wrote:
>>>> My initial though was to have following syntax:
>>>>    dom:[request|session|context]:<attribute-name>#<jxpath>
>>>> Xpath, and '#' symbol is obviously optional, and '#' was chosen for 
>>>> consistency with existing xmldb: protocol.
>>> Just some thoughts:
>>> - why "dom" only? We should also allow XMLizable objects.
>> "dom" is good and short protocol name. XMLizable can be (and should 
>> be) easily supported, too. I thought of JXPath, actually, which would 
>> support Java Beans and collections too.
> Ok, JXPath is used on the object in the attribute and returns the 
> object pointed to, if this object is XMLizable or DOM it is serialized 
> to XML otherwize the source throws an exception. One could of course 
> use Castor or Betwixt or something similar to XMLize any bean 
> structure, but I think that can wait to later. It would probably 
> require using some configuration files as well and would probably 
> complicate the use of the protocol.
>>> - what about using input modules?
> Seem like a good idea, as long as we keep the focus on XMLizable objects.
>> Good idea! Do we have upload module already? This will quickly 
>> deprecate part: protocol :)
> In that case I think we should have two protocols: "xmodule:" that is 
> XMLizable, and "module:", that takes care of things that are natural 
> to read and write as general octet streams. But I don't know, AFAIK 
> there are no modules that returns streams currently, does it realy 
> make sense to move stream handling functionality to modules. We have a 
> quite fine grained family of source protocol, that gives lot of 
> information about in what ways a source can be accesed, while modules 
> returns objects, and thus don't say anything all about how you can 
> access the object

I agree here: modules can handle objects (including DOM and XMLizable 
which are of interest here), but not streams.

>>> We already have some modules that give access to all the 
>>> above-mentioned attributes and more. This avoids code duplication, 
>>> improves consistency and allows further extension by simply adding 
>>> new input-modules.
>>> Considering this, we should find another name for the protocol: 
>>> "input-module" (too long), "module" (not significant enough), 
>>> "xml-module" (better)?
>> Still long ;-) How about "xmodule"? :) 

"xmodule" sounds good.

>> And then the protocol syntax becomes:
>>>  xml-module:<module-name>:<attribute-name>#<jxpath>
>>> E.g. "xml-module:session-attr:purchase-order#item[1]"
>> xmodule:session:purchase-order#item[1] is even better ;-) 
> Ok, seem good except for that session-attr is the name of the module 
> in the standard cocoon.xconf, so I think we should stick to that.


> Remaining question is what to do about the the output aspect of the 
> source. One of the reasons for me to wanting an dom: source is that I 
> want a convinient way to store XML output from the processPipelineTo 
> function in flowscripts (actually I think we should have a version of 
> it that takes a ModifiableSource name as input instead of an 
> I'm not that keen in leting strive for 
> generality kill one of my main use cases.
> My current implementation use just replace the attribute value with a 
> dom object created from the XML written into the output stream, when 
> used without xpath. With xpath it uses JXPath in lenient mode together 
> with o.a.c.util.jxpath.DOMFactory. This would be quite hard to 
> generalize to more general objects like JavaBean graphs, at least it 
> would require a quite heavy machinery with configurations for deciding 
> what factories that shoud be used for the various objects.
> For the time beeing I prefer to concentrate on writing to dom trees. 
> If I limit the scope of the xmodules, I will be able to put it in 
> bugzilla faster, so that people with other scratches to itch will be 
> able to do something about them :)

Let's stick to DOM for now: build a DOM from the data on the stream and 
assign it to the module and xpath.

But the way to do this assignation isn't clear to me yet: should we use 
output-modules, but in that case what about the xpath expression, or 
should we use input-modules when there's an xpath and output-modules 
when there isn't any?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message