You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/08/13 17:34:02 UTC

Re: Why does a Serializer doesn't have a setup method? Was:Re: Cocoon Contracts (was Re: Why does Action extend ThreadSafe ?)

Mariano Kamp wrote:
> 
> Hello Berin,
> 
>   your explanations are quite helpful. Just one little question:
> 
> >[..]
> 
> > 2) Generator: A generator performs XML generation from some external
> > source, whether it is a stream, an object, or database.  It must send SAX
> > events to the next component in a chain.  A Generator is always the first
> > component in a chain.  Due to the SAX implementation, it cannot be
> > ThreadSafe--but can be Pooled.
> 
> >[..]
> 
> > 4) Serializer: A serializer receives XML from a chain, and converts it to
> >    an external stream.  A Serializer is the last element in a stream.
> > Again, it has the same constraints placed upon it as Generator due to the
> > same issues.
> 
> I guess you are referring to the need to use instance variables? What I don't
> get is that there is no setup method in Serializer. I was already asking this
> once, but Giacomo just replied: "It is the way it is designed." Could you
> probably cast some light into the schadow?

I was refering to the SAX methods.  In regular use, it receives multiple SAX
events, so it does not have a single entry point, or a document scoping method.

>   So my real question is: If a serializer needs to have instance variables
> why shouldn't has it a setup() Method?

The absence of the Setup method is due to the lack of runtime behavior modification
ability.  A serializer should function the same way every time it is used, regardless
of runtime parameters.  That is the main reason it does not have a setup() method.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Why does a Serializer doesn't have a setup method? Was:Re: Cocoon Contracts (was Re: Why does Action extend ThreadSafe ?)

Posted by Mariano Kamp <mk...@codamax.com>.
On Wednesday 15 August 2001 07:37, giacomo wrote:
> On Mon, 13 Aug 2001, Berin Loritsch wrote:
> > Mariano Kamp wrote:
> > > Hello Berin,
> > >
> > >   your explanations are quite helpful. Just one little question:
> > > >[..]
> > > >
> > > > 2) Generator: A generator performs XML generation from some external
> > > > source, whether it is a stream, an object, or database.  It must send
> > > > SAX events to the next component in a chain.  A Generator is always
> > > > the first component in a chain.  Due to the SAX implementation, it
> > > > cannot be ThreadSafe--but can be Pooled.
> > > >
> > > >[..]
> > > >
> > > > 4) Serializer: A serializer receives XML from a chain, and converts
> > > > it to an external stream.  A Serializer is the last element in a
> > > > stream. Again, it has the same constraints placed upon it as
> > > > Generator due to the same issues.
> > >
> > > I guess you are referring to the need to use instance variables? What I
> > > don't get is that there is no setup method in Serializer. I was already
> > > asking this once, but Giacomo just replied: "It is the way it is
> > > designed." Could you probably cast some light into the schadow?
>
> Serializers purpose are to serialize SAX events into streams. So there
> is no need for stuff passed in by the setup method in
> SitemapModelComponent (at least so far).
Ok, here is an example. I have a serializer which task it is to produce 
charts. It gets all the data as SAX-Events. Currently it also gets the width 
and the height of the images to be produced within the data. This is the only 
point where I need to "mess up" my data, with parameters about how the 
container of the images should be rendered. I would have appreciated to pass 
it to the serializer in the setup method, actually reading from the request 
parameters. 

Currently I do know put this height and width in my "report definitions", 
which are generated in the very beginning of my pipeline and are the base for 
all the dbQueries needed etc. So I push this information from step one to the 
last step, without any need to use it in the steps between. 

The last transformer does some xslt and I could also pass the width and 
height in there, but haven't done so, because my current approach is not too 
bad either. My point is. I don't absolutely need a setup() method in a 
Serializer, but I was wondering why there is none.

Thanks for enlightening me ;-)

Mariano 



> > I was refering to the SAX methods.  In regular use, it receives multiple
> > SAX events, so it does not have a single entry point, or a document
> > scoping method.
> >
> > >   So my real question is: If a serializer needs to have instance
> > > variables why shouldn't has it a setup() Method?
> >
> > The absence of the Setup method is due to the lack of runtime behavior
> > modification ability.  A serializer should function the same way every
> > time it is used, regardless of runtime parameters.  That is the main
> > reason it does not have a setup() method.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: Why does a Serializer doesn't have a setup method? Was:Re: Cocoon Contracts (was Re: Why does Action extend ThreadSafe ?)

Posted by giacomo <gi...@apache.org>.
On Mon, 13 Aug 2001, Berin Loritsch wrote:

> Mariano Kamp wrote:
> >
> > Hello Berin,
> >
> >   your explanations are quite helpful. Just one little question:
> >
> > >[..]
> >
> > > 2) Generator: A generator performs XML generation from some external
> > > source, whether it is a stream, an object, or database.  It must send SAX
> > > events to the next component in a chain.  A Generator is always the first
> > > component in a chain.  Due to the SAX implementation, it cannot be
> > > ThreadSafe--but can be Pooled.
> >
> > >[..]
> >
> > > 4) Serializer: A serializer receives XML from a chain, and converts it to
> > >    an external stream.  A Serializer is the last element in a stream.
> > > Again, it has the same constraints placed upon it as Generator due to the
> > > same issues.
> >
> > I guess you are referring to the need to use instance variables? What I don't
> > get is that there is no setup method in Serializer. I was already asking this
> > once, but Giacomo just replied: "It is the way it is designed." Could you
> > probably cast some light into the schadow?

Serializers purpose are to serialize SAX events into streams. So there
is no need for stuff passed in by the setup method in
SitemapModelComponent (at least so far).

Giacomo

>
> I was refering to the SAX methods.  In regular use, it receives multiple SAX
> events, so it does not have a single entry point, or a document scoping method.
>
> >   So my real question is: If a serializer needs to have instance variables
> > why shouldn't has it a setup() Method?
>
> The absence of the Setup method is due to the lack of runtime behavior modification
> ability.  A serializer should function the same way every time it is used, regardless
> of runtime parameters.  That is the main reason it does not have a setup() method.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org