cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon Ant task
Date Fri, 28 Sep 2001 09:37:26 GMT
Gianugo Rabellino wrote:
> 
> On Fri, Sep 28, 2001 at 09:43:29AM +1000, Jeff Turner wrote:
> > >   <target name="cocoon">
> > >     <cocoon destination="${base.dir}/docs"
> > >             context="${base.dir}/documentation"
> > >             workdir="${base.dir}/work"
> > >             urifile="${base.dir}/documentation/root.uris"
> >
> >
> > I was wondering, would it be possible to have Ant automatically
> > determine which *.xml files are "out of date", and use that list instead
> > of hardcoded lists in *.uris files?
> 
> It would be possible, but there is a problem with the whole sitemap
> concept: it's not possible, in a general way, to associate a "virtual"
> URI, such as the one matched in the sitemap to a concrete xml file
> (or resource, or whatever). The fact that a list containing "foo.html"
> and "bar.html" depends on "foo.xml" and "bar.xml" and the assumption
> that, being the source file unchanged, the resource should not be
> processed, is outside the scope of an Ant task: it should be a Cocoon
> responsability to perform these checks and decide what to do.
> 
> This is how Cocoon's own caching works, but I really don't know if
> the CLI environment can use it in different runs.

I don't know if the current cache implementation does so (haven't tested
yet), but for sure this is something that only Cocoon can control since,
as Gianugo explained, we are not dealing with files anymore, but with
URI spaces that are mapped to the file system by cocoon internal
machinery.

Probably few of you noted the link-translating capabilities of the CLI:
let's make an example. Suppose you have something like

 http://host/path/file1
 http://host/path/file2

where the first x-links to the second.

Suppose that depending on some agent settings, they are serialized as
PDF.

The CLI is capable of:

 1) perform xlink crawling.
 2) perform URI -> filesystem name mangling.
 3) perform internal link translation based on previous filename
mangling.

This results in two files named

 file1.pdf
 file2.pdf

but file1.pdf contains links that point to file2.pdf.

So the PDF snapshot of the live URI space is fully browsable on disk.

This is possible because of the xlink semantics and view capabilities of
Cocoon2: the link view of a resource returns all the xlinks that the
resource has and the link-translating view performs link translation
*before* the format is actually serialized. So, this method is general
enough on *any* binary format and we don't have to implement
link-translating behavior for every binary format we support (as some
web-site grabbers have to do).

Note that this link-translating capability is disabled for security
reason if the call comes from a servlet.

With this pretty complex machinery, it's evident that Ant cannot
understand if one of the two has changed.

So, yes, a great feature to have but it should be Cocoon's cache to
handle this, Ant cannot.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message