cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: DOM Protocol, Was: Revised ResourceLoadAction posted...
Date Tue, 18 Nov 2003 14:19:25 GMT
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

>
>> 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"? :) 

> 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 
java.io.OutputStream). 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 :)

/Daniel



Mime
View raw message