forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: Impossible to integrate PDF documents in forrest site?
Date Sat, 24 Aug 2002 08:54:23 GMT
On Thu, Aug 22, 2002 at 05:30:48PM +0200, Marc Portier wrote:
> > -----Original Message-----
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > >
> > >   myfile.pipeline.extension
> > >
> > > I like it.
> >
> > Expanding a bit on this:
> >
> > We can dictate that every file in the contents can
> > have a double extension.
> 
> there was even mentioning of more then two at the moment the idea
> got me going ....
> <snip
> from="http://marc.theaimsgroup.com/?l=forrest-dev&m=1029759626196
> 43&w=2">
> Next to that I don't see why there would be no room for something
> like
> testresult.metric.svg.jpg?
> 
> Looking at it from this angle the multiple parts of the new
> extension become like a route or a trail describing how to
> get from *.metric.xml to jpg via svg. (Supposing there could
> be more then one route)

Back in Cocoon 1 days, each XML file had processing instructions at the
top, telling Cocoon what series of transformations to apply to it, and
what it's final content type should be:

<?cocoon-process type="xsp"?>
<?cocoon-format type="text/html"?>

With Cocoon 2, the whole idea of the sitemap was to get rid of this, and
have a single point of control.

Now the idea of having 'myfile.pipeline.extension' seems identical to
PIs, only not as clean. It takes control away from the sitemap.
Subversion of control.

Or have I missed something? What's wrong with a simple action that checks
of a PDF exists?


--Jeff

> </snip>
> 
> 
> > The output of Forrest will never show the internal
> > extension, it's only
> > a hint to the pipelines about the content of the file.
> >
...
> -marc=

Mime
View raw message