Re: Add support for Googles sitemap protocol?

[Rasik Pandey]

Hello,

Ross wrote:
>>http://svn.apache.org/repos/asf/cocoon/trunk/src/java/org/apache/cocoon/generation/LinkStatusGenerator.java
> > 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 forrest.properties 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
> forrest.properties. So again, the config needs to be in the plugin.

Agreed...

> 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.

--
Regards,
Rus
www.discountdracula.com