forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rasik Pandey <>
Subject Re: Add support for Googles sitemap protocol?
Date Fri, 22 Jul 2005 19:31:17 GMT

Ross wrote:
> > would do the trick, although it would have to be modified to make a call
> > to get the "last-modified" header, so hopefully we could get that added
> > to a future release of cocoon. With a quick examination of the code, it
> > looks like it will crawl a URL and generate an xml report, allowing
> > includes and excludes expressions.
> We can create a new generator that extands the LinkStatusGenerator and
> house it here. If Cocoon want it we will remove it from here at a later
> date.

I have a few issues with the approach which I proposed, hopefully you can 
help me make some sense about my reservations. First, since views are 
orthogonal to each sitemap the cocoon-view=links required by the 
LinkStatusGenerator and therefore must be declared in the parent sitemap 
which does the core matching. Secondly, in building such a plugin for 
forrest, the plugin-sitemap would have to override/redeclare a number of 
pipeline match(s) in order to have access/provide to the necessary request 
header,"last-modified", as there doesn't seem to be a generic means for 
providing this information and passing it up to parent pipeline match(s) so 
they are conditionally added to the request headers. Overriding many 
pipelineThis doesn't seem very maintainable. Would anyone have any ideas on 
how to achieve this or an alternative approach?

> This should not be configured from skinconf.xml. There a few reasons for
> this, firstly it has nothing to do with the skin, which is about the
> look and feel of the site. Secondly because skins (and therefore
> skinconf.xml) are being deprecated in 0.8 in favour of views. Finally
> this should be an output plugin and therefore needs to be configured
> from the plugin.

Point taken.

> The variables in the sitemap, such as {project:stylesheets} are defined
> in forrest.xconf and are given values from during Ant
> script (the init target if I remember correctly). However, since this is
> a plugin we do not want to be adding new config values to
> So again, the config needs to be in the plugin.


> How do you do that?
> We don't know yet. We have discussed it quite a few times but have not
> yet come up with a final solution. Although Thorstens recent work on
> View configuratoin has made some of the options we talked about possible.
> Since we don't yet know a solution for this perhaps we can work the
> other way around. When you get to the point of needing to add these
> configurations tell us exactly what you need to do and we will use it as
> a use case for defining the per plugin configs.

Will do, thanks.

Rus <>

View raw message