cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] Webdavapps with Cocoon
Date Tue, 29 Jul 2003 09:51:38 GMT

Nicola Ken Barozzi wrote:
> Sylvain Wallez wrote, On 29/07/2003 9.35:

<snip />

>> It's basically RequestFactories coming back on the table. But this 
>> time, this must be more than a simple class to handle file uploads.
> Yes, IMHO we need another concept, and present it in the sitemap.
> Before, I had called it "locators", as a Generator should generate XML, 
> not really care where the data comes from.
> Then we had source protocols, that seemed to have resolved all 
> pre-generation problems, as it basically does what a "locator" should do.
> But hey, guess what, we came up with "input modules", that act similarly 
> to sources in the "context/objectspace/environment" part.
> And now we are talking of making a unified view of these?

possibly totally out of the blue:

when working recently on the jxpath based woody binding and flow 
integration I got inflicted by the elegance of using jxpath for 
both subnode-identification inside XML docs as wel as javabean 

from this angle, and strangly mixing them with personal thoughts 
provoced by words 'locator', 'source' and 'unified view'

could we come up with uri's that not only direct us to sources 
but maybe even to objects located in the 'environment/context' ?

possibly reusing jxpath in both cases for the sub-source 
and adding some generic bean-toXML doing by some ObjectSource 

I understand there are more then just subtle differences between 
XML docs and Java objects, but maybe from the perspective of
- retrieving/finding them (source resolving)
- locating stuf inside them (jxpath)
- pulling parts of it through publication pipes (toSAX)
those differences are not to be seen?

if I still catch the general flow of this thread then the hookup 
with the sitemap can become something like

--> http-request
   --> sitemap
     --> extractor (extracting parts of the request and
                    making them available under these
                    new kind of uri's)
       --> matcher
         --> components (including flow) havig access to them

disclaimer: just jotting down the associations in my brain... the 
above might be doing total injustice to what inputmodules are 
doing, please help me see if that is the case...

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message