You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Andreas Hartmann <an...@apache.org> on 2011/05/09 15:29:26 UTC
Re: Cocoon caching with multiple pipelines
Hi Robin,
Am 27.04.11 12:49, schrieb Robin Taylor:
> It looks like the default generator is an extension of FileGenerator
> that I assume takes as input the output from the<map:serialize
> type="xml"/> step in the preceding pipeline.
what do you mean with "preceding pipeline"? What exactly does the custom
FileGenerator use as the source? A hard-coded cocoon:/ call?
> I also assume therefore
> that the FileGenerator uses the incoming xml to build its validity
> object and therefore spots that it has changed ?
No, the standard FileGenerator uses the validity of the source. The
incoming XML cannot be used, since it would have to be re-generated to
spot changes, which kind-of renders the caching mechanism useless.
Typical source validities are based on last modification dates,
expiration times and similar concepts. Example: If you pass a file URI
to the FileGenerator, the last modification date of the file is used. If
you pass a cocoon:/ URI to the generator, the validity of the
corresponding SitemapSource (representing the result of the called
pipeline) is used.
HTH,
-- Andreas
>
> Thanks again.
>
>
>
> On Wed, 2011-04-27 at 10:54 +0100, Thorsten Scherler wrote:
>> On Wed, 2011-04-27 at 09:41 +0100, Robin Taylor wrote:
>>> Hi Thorsten,
>>>
>>> Thanks again and apologies for drip-feeding the questions.
>>>
>>> In the code I'm looking at it appears the second pipeline has an empty
>>> map:generate ie.<map:generate/>. I assume this results in the second
>>> pipeline using the output from the first pipeline.
>>
>> no, a<map:generate/> means cocoon uses the default generator
>> configured for this sitemap.
>>
>> If is does not uses a src is most likely a "special" generator such as
>> e.g. http://cocoon.apache.org/2.1/userdocs/request-generator.html
>>
>> Using that as an example:
>> <map:generators default="request">
>> <!-- This will turn on attribute generation on by default -->
>> <map:generator name="request" src="org.apache.cocoon.generation.RequestGenerator">
>> <map:parameter name="generate-attributes" value="true"/>
>> </map:generator>
>> </map:generators>
>> ...
>> <!-- This will turn on attribute generation for this invocation only.
>> -->
>> <map:match pattern="request">
>> <map:generate/>
>> <map:serialize/>
>> </map:match>
>>
>> As you see the<map:generate/> would here generate a xml representation
>> of the request and not use a former match/pipeline as input.
>>
>> salu2
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon caching with multiple pipelines
Posted by Robin Taylor <ro...@ed.ac.uk>.
Hi Andreas,
On Mon, 2011-05-09 at 14:29 +0100, Andreas Hartmann wrote:
> Hi Robin,
>
> Am 27.04.11 12:49, schrieb Robin Taylor:
> > It looks like the default generator is an extension of FileGenerator
> > that I assume takes as input the output from the<map:serialize
> > type="xml"/> step in the preceding pipeline.
>
> what do you mean with "preceding pipeline"? What exactly does the custom
> FileGenerator use as the source? A hard-coded cocoon:/ call?
>
Yes, that's it exactly.
>
> > I also assume therefore
> > that the FileGenerator uses the incoming xml to build its validity
> > object and therefore spots that it has changed ?
>
> No, the standard FileGenerator uses the validity of the source. The
> incoming XML cannot be used, since it would have to be re-generated to
> spot changes, which kind-of renders the caching mechanism useless.
> Typical source validities are based on last modification dates,
> expiration times and similar concepts. Example: If you pass a file URI
> to the FileGenerator, the last modification date of the file is used. If
> you pass a cocoon:/ URI to the generator, the validity of the
> corresponding SitemapSource (representing the result of the called
> pipeline) is used.
>
Ok, I think I'm barking up the wrong tree here. Thanks very much for all
your help, much appreciated.
Cheers, Robin.
> HTH,
>
> -- Andreas
>
>
> >
> > Thanks again.
> >
> >
> >
> > On Wed, 2011-04-27 at 10:54 +0100, Thorsten Scherler wrote:
> >> On Wed, 2011-04-27 at 09:41 +0100, Robin Taylor wrote:
> >>> Hi Thorsten,
> >>>
> >>> Thanks again and apologies for drip-feeding the questions.
> >>>
> >>> In the code I'm looking at it appears the second pipeline has an empty
> >>> map:generate ie.<map:generate/>. I assume this results in the second
> >>> pipeline using the output from the first pipeline.
> >>
> >> no, a<map:generate/> means cocoon uses the default generator
> >> configured for this sitemap.
> >>
> >> If is does not uses a src is most likely a "special" generator such as
> >> e.g. http://cocoon.apache.org/2.1/userdocs/request-generator.html
> >>
> >> Using that as an example:
> >> <map:generators default="request">
> >> <!-- This will turn on attribute generation on by default -->
> >> <map:generator name="request" src="org.apache.cocoon.generation.RequestGenerator">
> >> <map:parameter name="generate-attributes" value="true"/>
> >> </map:generator>
> >> </map:generators>
> >> ...
> >> <!-- This will turn on attribute generation for this invocation only.
> >> -->
> >> <map:match pattern="request">
> >> <map:generate/>
> >> <map:serialize/>
> >> </map:match>
> >>
> >> As you see the<map:generate/> would here generate a xml representation
> >> of the request and not use a former match/pipeline as input.
> >>
> >> salu2
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org