setup() method for components vs. avalon lifecycle

[Geoff Howard <gh...@crosswalk.com>]

In the process of writing up a tutorial on writing a C2 Generator, I've run
across what seems to be an important question I can't find documented
(imagine that).  In a discussion on cocoon-docs, Jens Lorenz suggested
implementing Parameterizable to get at request parameters in the sitemap
(for the context, see
http://marc.theaimsgroup.com/?l=xml-cocoon-docs&m=102828311607253&w=2).  

Obviously, there are a number of ways to get at request parameters - not the
point here.  The questions this has raised are:

1) I had thought that setup(...) was an avalon defined method, but
apparently it's not.  Is there information on how this method was chosen
architecturally?
2) My understanding is that parameterize(...) is only called once, during
the life of a component.  I further assume that this means that each request
for a generator would not call this method again, and that
reparameterize(...) would have to be employed.  Is this correct?
3) Is the correct way to get at parameters in a C2 component/generator to
use the org.apache.avalon.framework.parameters.Parameters reference passed
in to setup(...)?
4) How is the current lifecycle of C2 components different than that
described at
http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html
currently?

Thanks,
Geoff Howard


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

RE: setup() method for components vs. avalon lifecycle

[Vadim Gritsenko <va...@verizon.net>]

> From: Geoff Howard [mailto:ghoward@crosswalk.com]
> 
> In the process of writing up a tutorial on writing a C2 Generator,
I've run
> across what seems to be an important question I can't find documented
> (imagine that).  In a discussion on cocoon-docs, Jens Lorenz suggested
> implementing Parameterizable to get at request parameters in the
sitemap
> (for the context, see
>
http://marc.theaimsgroup.com/?l=xml-cocoon-docs&m=102828311607253&w=2).
> 
> Obviously, there are a number of ways to get at request parameters -
not the
> point here.  The questions this has raised are:
> 
> 1) I had thought that setup(...) was an avalon defined method, but
> apparently it's not.  Is there information on how this method was
chosen
> architecturally?
> 2) My understanding is that parameterize(...) is only called once,
during
> the life of a component.  I further assume that this means that each
request
> for a generator would not call this method again,

That's right.

> and that reparameterize(...) would have to be employed.  Is this
correct?

That's not exactly right. Reparameterize *could* be called (not that
somebody *will* call it in current implementation) only when sitemap has
been changed, and generator is given new parameters.

In current sitemap implementations, old generator will be discarded and
new created (and not only generator, but sitemap itself too).


> 3) Is the correct way to get at parameters in a C2 component/generator
to
> use the org.apache.avalon.framework.parameters.Parameters reference
passed
> in to setup(...)?

What parameters we are talking here about? Declaration-time (inside of
<map:components/>) or invocation-time (inside <map:pipelines/>)?

Declaration time: either Configurable or Parameterizable.
Invocation time: from setup() method.
Request parameters: from request object, but you know this ;)


> 4) How is the current lifecycle of C2 components different than that
> described at
>
http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html
> currently?

Cocoon uses Excalibur. Whatever supported by excalibur is supported by
Cocoon.

setup() and generate() methods are Cocoon business methods, defined by
Cocoon and are not related to Avalon in any sense.


Vadim

 
> Thanks,
> Geoff Howard


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