forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thorsten.scherler....@juntadeandalucia.es>
Subject Re: svn commit: r568047 - /forrest/trunk/main/targets/site.xml
Date Wed, 22 Aug 2007 06:20:13 GMT
On Wed, 2007-08-22 at 12:22 +1000, David Crossley wrote:
> Ross Gardler wrote:
> > Author: thorsten
> > >Date: Tue Aug 21 03:02:42 2007
> > >New Revision: 568047
> > >
> > >URL: http://svn.apache.org/viewvc?rev=568047&view=rev
> > >Log:
> > >Adding --uriFile argument to the cocoon cli call. This way one can set 
> > >project.urifile to the uris that should be included. see 
> > >http://cocoon.apache.org/2.1/userdocs/offline/cli.html for more 
> > >information.
> > 
> > Does this mean that only files mention in the uriFile are generated? 
> > It's not clear in the docs.

That depends on the follow-links="true|false", but yes if you turn off
the follow links then the project.start-uri and all links in the
project.urifile are crawled only.

> > If this is the case then we could write a script to create this uriFile 
> > from the last modified dates of files and solve the problem of 
> > regenerating every page in the content object.

Yes, it is possible, but we needed another tweak. Like in the other
commit:
+ <arg value="--followLinks=${project.followLinks}"/>

This allows to set the parameter without touching the cli.xconf.

The non trivial task is the uriFile itself. Since a source does not have
to be based on a file system file one would need to crawl the whole site
and store the http-headers regarding caching.

Further when adding or removing nodes in the site.xml some parts of the
site needs to be rebuilded even if the underlying source has not
changed. The reason in html is e.g. ATM the menu which is reflecting the
navigation.

> Note that both of those new parameters can be specified
> on a per-project basis using the Cocoon conf/cli.xconf
> configuration file.

Yes, but in an environment where you need to generate only a couple of
pages but different ones the cli.xconf is too unflexible. 

In my current project I have a couple of ssi includes file that I need
to generate. I am using in my ant based project:
<!-- macro for calling forrest site (with urifile)-->
  <macrodef name="site-set">
    <attribute name="uri"/>
    <attribute name="build"/>
    <attribute name="urifile"/>
    <sequential>
      <antcall target="site">
        <param name="project.home" location="${exporter.home}"/>
        <param name="project.start-uri" location="@{uri}"/>
        <param name="project.build-dir" location="@{build}"/>
        <param name="project.urifile" location="@{urifile}"/>
      </antcall>
    </sequential>
  </macrodef>

And can then use it in my targets like e.g.:
<!-- Generating the list of urlis -->
<echo file="${ssi.build}/uris.txt">/menu-boja.internal
/foot.internal
/more/links</echo>
<!-- Generate head/left/foot -->
<site-set uri="/head.internal" build="${ssi.build}"
      urifile="${ssi.build}/uris.txt"/>

>  For example, see site-author/conf/cli.xconf
> and search for "uri-file" and "follow-links".

If I use the cli approach I would need to generate the cli.xconf
dynamically. In my use case only the uris are changing so no need for
the cli.xconf. I used this approach before but since I have now many
other pages as well that I need to generate I need something less
heavy. 

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Mime
View raw message