Nicola Ken Barozzi wrote:
> ReLook at how o.a.c.Cocoon is setup and used in Main.java, and you'll
> see how nobody would use it in its code, it's way too complicated.
> We had already talked a bit about this, and we thought that maybe making
> a second CocoonBean class would be better with regards to compatibility
> with old code that relies on Cocoon.java, but actually I would prefer
> Cocoon.java to be that bean/service.
That is why I'm writing this bean. The Cocoon.java class scares the willies out of me.
> >> void setInput(Object input);
> >> void setOutput(Object output);
> >> void morph() throws MorphException;
>
> Ok, I've seen it now and it's interesting.
> From what I've quickly seen, it still depends on the
> filesavingenvironment, and does not have a signature like the above example.
Firstly, I haven't yet got my head around the different environments and their purpose
yet. So I just took the FileSavingEnvironment straight out of the CommandLine version
and used that, as it suited my purpose.
Secondly, if you look into CocoonBean.java, you'll see an unimplemented processURI
method. That should do much what you are suggesting, using the following code:
CocoonBean cocoon = new CocoonBean("c:/working", "c:/context");
String URI = "cocoon:/blah/foobar.html?page=1";
File f = new File("foobar.html");
FileOutputStream fos = new FileOutputStream(f);
cocoon.processURI(URI, fos);
Basically, you pick a URI and pass it to any output stream you like. I think I'll have
a go
at implementing this now.
I've also gone through and added the Apache copyright and a class description to each
class which I'll submit soon.
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
