I'm thinking that you can't do you would like to do because as I understand it, the pipeline is assembled before generation starts. You're talking about putting a pipeline together based on something that happens in the generation component. Cart before the horse. Closing the barn door after . . . oh never mind. Perhaps you can pass the response code as an attribute in your SAX events and do your conditional processing in the transformer.

Charles

David Kavanagh wrote:

I think people misunderstood something I said.
One parameter to the setup() method in AbstractSAXTransformer is of type Parameters. I was asking if this is considered mutable. Should I be able to modify the Parameters object (by adding another key/value)? Is it OK to pass values forward in the pipline by this method?
Irv suggested using the session object which I'll also go along with. I'm just wondering what is the accepted mechanism.


David

Conal Tuohy wrote:

-----Original Message-----
From: David Kavanagh [mailto:[EMAIL PROTECTED]



Well, maybe..
Just as a matter of protocol, isn't adding a new
component something a cocoon user would do? I'm not
really messing with cocoon internals. I'm just
implementing published interfaces.



except didn't you ask about passing an extra parameter to a method in one of these interfaces? I think your problem/question is architectural, and that's why I think cocoon-dev would be better.

Con



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to