Re: Polishing the flow contracts

[Stefano Mazzocchi]

Pier Fumagalli wrote:
On 30/3/03 14:43, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:


Cocoon Object:
[...]
  cocoon.process(uri, dict, output


There's another thing I don't really like (and being the implementor of the
feature, yes, it's my own fault)...
Currently to the "process" method we ought to pass a nice OutputStream
instance, which we can create using the Rhino extensions to acess Java
objects.
Now, I'd rather like to see it more "factored" out, a some sort of
"OutputStreamFactory", like we do for source files...
Anyone has some design hints on how we could achieve that? Anyone else sees
it as I do as a "design hack" ???
I used it yesterday and I agree with you. Using LiveConnect (the 
javascript/java connector) for such a thing smells of hacky.

We already have the concept of WriteableSources and I think the Source 
selector is already available thru the cocoon.componentManager.

But you would trade

 process ("whatever",{},new java.io.FileOutputStream(file));

for something like (sorry for the formatting and the pseudo-code)

 var source = cocoon.componentManager.get(
    Packages.org.apache.excalibur.source.WriteableSource.ROLE + "/file
 );
 source.setDest("whatever");
 cocoon.process("whatever",source);
which is for sure better but can't go along without LiveConnect.

there is one advantage thought: currently, there is no easy way to 
resolve a uri againts the servlet context real path. This abstraction 
could do such a thing transparently and enforce an inversion of control 
that would definately ease portability across platforms.

Thoughts?

Stefano.