cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Polishing the flow contracts
Date Mon, 31 Mar 2003 09:17:24 GMT
Pier Fumagalli wrote:
> On 30/3/03 14:43, "Stefano Mazzocchi" <stefano@apache.org> 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.


Mime
View raw message