forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <KPiroum...@protek.com>
Subject RE: Impossible to integrate PDF documents in forrest site?
Date Thu, 22 Aug 2002 13:02:36 GMT
> From: Marc Portier [mailto:mpo@outerthought.org] 
> 
> IMHO trail-expressing file-extensions could solve the thing
>   *.doc.pdf could be matched onto a pipeline that starts with an
> xdoc and runs it into a pdf
> 
> as I explained earlier this mechanism could solve more then this
> alone.

This kind of matchers eplicitely state that you have PDF output. It's Ok
when you have links like 'PDF version'. But for links like 'Print-friendly
version' I prefer more semantical URLs, like: /print?doc=mydoc or
/mydoc.xml.print (or even /mydoc.xml/print)

> 
> 
> as for the other proposals:
> > >
> > > IMHO we should just add a matcher that matches every
> > >
> > >     context://include/**
> > >
> > > to
> > >     /content/include/**/*.*
> > >
> > > so that we can easily include static content.
> >
> 
> as easy as the centralized images :-)
> IMHO this is not how people think about having inlined or
> referenced resources
> having an image or resource-bank is a different issue I guess.
> 
> By the way an absolute reference: /include in our xdocs  will
> open up more trubbels of the tabs-hack kind. (where we prefix the
> tab-hrefs with /forrest/ because it is published like that on
> krysalis.org and outerthought.net?)
> All absolute links we add in our xdocs kill the posibility to
> publish the generated site at any other location then the root.
> 
> This we should solve in any case. Maybe a transformer, just
> before the 2html.xsl, that 'relativises' all generated links
> could solve this?

+1. 
Similar approach is used in Struts' html taglib. If you use <html:img
src="pic.jpg" /> it is then generated as <img src="/app/pic.jpg" />, where
'app' is your application context path.

> 
> > IMHO there must be special matcher for static PDFs
> > (*.pdf) and a separate
> > matcher for Printer-friendly (maybe *.prnt or
> > something like that). Printer
> 
> yes, but calling it *.prnt instead of *.docs.pdf only pushes the
> problem up the chain
> - what if a genuin *.prnt comes along (lame, I know, but true
> :-))

Ok, let's call it *.printable. BTW, my proposal is almost the same as yours.
I have nothing against the double extension format. I just want more
semantical meaning: 'printable' instead of explicit 'pdf'. This way your can
keep your URLs unchanged, but changing only the pipeline you'll get
different output (PDF, RTF, Plain text, simplified HTML, etc.).

> - how will you print-friendly anything that is not originally in
> xdoc format? in other words: what if you need multiple pipelines
> to pdf, starting from different starting doctypes?

Don't see problems with this. There are plenty of ways for generating
different content in Cocoon depending on your needs.

> 
> > friendly does not always mean PDF, it can be a
> > simplified HTML version of
> > the same doc.
> >
> 
> very true.
> Though: I think the skin or the person creating the link in his
> document should decide that, not the sitemap.

I don't want the person to change his links, but only the sitemap pipeline.
Doesn't this make sense?

> 
> > Another solution is to use an action that will check
> > if there is a file
> > ready to server and if not found then only generate
> > PDF on fly (and maybe
> > store the file).
> >
> 
> don't fully get this...

Hm... Sorry, seems that I've forgot that Forrest still is not used as a
webapp, but offline generator. 
What I've been saying is that if you need to generate PDFs from a webapp
then it'd be fine to generate them on the first request, save somewhere and
then serve as static resource using a Cocoon reader and not
generate-transform-serialize pipeline.

Konstantin

> 
> regards,
> -marc=
> 

Mime
View raw message