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.
Yep.
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 :)
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
