Peter Donald wrote:
> I am not sure I fully understand them in this case. So heres my opinion and
> you can tell me how it fits into your model ;) I think the transaformation
> pipeline (and possibly serializers) should be completely internal to the
> proposed cocoon block.
I fully agree with that.
> However it should be be fair game for the block to have parameters passed in.
Well, of course, you have to pass some data in, in fact, a request is
"some data in", I would say. But do you really want to fake a request to
have access to this Cocoon block?
> One of these parameters would of course designate the transformation
> pipeline.
This "parameter" is normally called URI. :) And this is what it should
remain. In fact, a URI is "uniform resource identifier", right? so it
"identifies" a resource (a pipeline, in this case).
> But the question is could one of the parameters passed in be the
> source to be transformed/processed? I'm not sure.
Well, look: I see it very simple: if you pass the document that should
be processed, you are the generator, then your concern is to generate
something and the block concern would be to transform it.
But Cocoon is designed to be in control of the URI space, otherwise
there is no way you can separate concerns: you ask for something (a
service, a page, in general: a resource) and then Cocoon gives it to
you.
This doesn't mean you can't pass things to Cocoon (as it doesn't mean
you can't do HTTP POST actions to Cocoon, even POST with XML payload
such as SOAP requests), but that this must be information used by Cocoon
not used by "YOU" to drive Cocoon behavior.
Hopefully, the difference is clear. If not, please tell me.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
