forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <...@outerthought.org>
Subject RE: Impossible to integrate PDF documents in forrest site?
Date Thu, 22 Aug 2002 14:02:39 GMT

> -----Original Message-----
> From: Piroumian Konstantin [mailto:KPiroumian@protek.com]
> Sent: donderdag 22 augustus 2002 15:03
> To: 'forrest-dev@xml.apache.org'
> Subject: RE: Impossible to integrate PDF documents in
> forrest site?
>
>
> > 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)
>

euh yes...
but we are creating off line content...
you should decide at generation time what type of doc you want
behind the link.
What mime-type needs to go with *.print?
Under which filename do you store /print?doc=mydoc
...

> >
> >
> > 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.
>

Sort of.
For all expressed as absolute links (expressed in @href, @src)
there should be a transformer (really at the end of the chain)
that translates them in the same link prefixed with as many ../
as the depth of the current-request.

Only then we will be able to just move our stuff to any sub-path
on any http-server

> >
> > > 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.

it is.

> I have nothing against the double extension format. I

damn, I am still looking for arguments against it. :-)
seriously, I think this could solve a lot of issues, and clear up
our URI namespace a lot.


> 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.).
>

I get your statement (in theory)
However: does forrest decide for all projects using it what the
encoding format of 'printable' is?
(since we offer the pipelines)

But I do catch your drift: URL's are human interface things.  You
want those to be semantically rich.

> > - 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.
>

as long as you can express those needs inside the boundaries of
the URL
that is what the discussion is about: where to state what we
need:
1. in a prefix /include or /print
2. in an argument ?print=pdf
3. somewhere **/print-me-please/** or **/print-*.*
4. in a suffix:  be it sematical rich: *.printable, or
technically rich: *.doc.pdf

I tried earlier this week to set up-front some ideas on how we
should devide the URI namespace.
I proposed somewhat to keep
- the leadig part for addressing (finding) stuff
- the trailing part for deciding on the pipeline to use.

Since we are talking static files I am afraid the only
'semantical tention' we can create is between the {label} and the
{link}:
<a href="{link}"> {label} </a>

> >
> > > 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?
>

It does.
I think you get the same effect (as is now) when letting the skin
decide what the technical meaning of 'printer-friendly' is

> >
> > > 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.

yep: same goes for the *.printable thought (no mime-type?)


-marc=


Mime
View raw message