cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: DOM Protocol, Was: Revised ResourceLoadAction posted...
Date Tue, 18 Nov 2003 14:44:31 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.

Of course, it can wait.

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

I think one is enough. If obtained Object can be streamed, it can be 
then parsed using XMLParser. But this, of course, also can wait, no need 
to implement all these right away.

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

RawRequestParameterModule can return uploaded Part which will have 
File...... Hmm... :)

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

But it should work if you want to stick DOM as an attribute of some 
JavaBean, right?

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

Sure! Don't take every wild thought too close, don't let them slow you 
down to a halt :)

Sylvain Wallez wrote:

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

It's getting messier with modules... Ideally same module type should be 
used everytime... Any chance of output modules providing xpath API?


View raw message