Rasik Pandey wrote:
Hello,
Ross wrote:
>>http://svn.apache.org/repos/asf/cocoon/trunk/src/java/org/apache/cocoon/generation/LinkStatusGenerator.java
<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.
Agghhhh!!! There's that term "views" again.
We have a real problem here in Forrest at the moment. Views are being
used to refer to two different things (views in Eclipse and views, the
replacement for skins). Now we seem to have a third use, I assume this
is sitemap views (funnily enough I said this may become a conflict in
another mail earlier today, never thought it would already have happened
in my inbox).
I'm going to delay responding to this because one of the things that
happened at the Hackathon is that Ferdinand looked at an alternative
method of identifying which pages were regenerated in a run. Perhaps we
should wait to see if he thinks it can be applied here.
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?
Internal plugins are for this kind of thing. However, as they stand they
don't make the code much more maintainable.
A possible solution is to use Cocoons new block sitemap loading
features. This was demonstrated to me at the Hackathon (thanks Daniel),
it provides a way for plugins to extend existing sitemaps (and other
plugins). I need to do some experimentation with this so you should
proceed with an internal plugin for now, we'll address the
maintainability when experiments are complete.
Ross
