Stefano Mazzocchi wrote:

on 6/27/03 11:48 AM Stefano Mazzocchi wrote:



As for implementing this, I planned to look into this today.



Ok, I dived into the code and I found where the problem is. The call to the sitemap invocation is located in the class

org.apache.cocoon.components.flow.AbstractInterpreter

and explicitly in the methods process(...) and forwardTo(...)

IIRC, the forwardTo() method was written by Ovidiu and uses a sitemap
redirector. The process() method was written by Pier and directly
obtains the pipeline and invoques it from the sitemap.

I would love to see the different approaches unified, whichever is
easier to adapt.

Both end up calling the method process(...) of the o.a.c.Processor
interface while (if I'm not mistaked) they should be calling the
processInternal() method.

In short, the flow ends up emulating a request as it came from the
outside, while it should emulate it as it came from the inside (as the
cocoon: protocol does)

Now, the change between process() and processInternal() is not that
trivial because the second returns a ProcessingPipeline while the first
returns a boolean and I have no clue on what I should do with that
pipeline, expecially regarding how to setup the environment and all
those things. I've patched it locally but I end up screwing up the
environment (I suppose) and I end up having NPE on component .release()
which is not nice at all.


In Cocoon 2.0, there was not so much difference between internal and external processing on the Processor interface. Things have changed in 2.1 due to changes in the cache system, which now require to build the pipeline to get its validity (Carsten, tell me if I'm wrong).


So the current situation in the sitemap engine (inherited from the 2.0 architecture), is that a call to process() is considered as external while a call to processInternal() is considered as... internal.

Now we see that tying internal/external to the called method is not the way to go, since we the flow calls process(), and such calls should be considered as internal.

So my suggestion is to strongly separate these two different notions. The results are that :
- internal/external should be a property of the environment object : add a new Environment.isInternal() method.
- Processor.processInternal() should be renamed to buildPipeline().


This separation can then allow any kind of combination.

What do you think ?

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




Reply via email to