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:45:50 GMT
right on,

> > as easy as the centralized images :-)
>
> ;-)
>
> Initially I thought that we would keep the resources separate.
> Hence the content/xdocs directory hierarchy.
> But since we will be merging all the content types in
> a single dir, we
> might as well do content/forrest, to indicate that the
> content will be
> usable by Forrest.

don't really get this.

<snip />

> > All absolute links we add in our xdocs kill the posibility to
> > publish the generated site at any other location
> then the root.
>
> Ok.
>
> > This we should solve in any case. Maybe a transformer, just
> > before the 2html.xsl, that 'relativises' all generated links
> > could solve this?
>
> Hmmm...
>

I like the sound of you thinking :-)
Something you don't like?


<snip />

> > very true.
> > Though: I think the skin or the person creating the
> link in his
> > document should decide that, not the sitemap.
>
> Hmmm...
> One problem is that we link to future results of the
> docs, not the docs
> per-se.
> IE we link to seeme.html but the source file is seeme.xml.
>
> This is because we link to a URI-space, not the
> content dir layout.
>

yes.
Somewhere I stated:
<snip
from="http://marc.theaimsgroup.com/?l=forrest-dev&m=1029759626196
43&w=2">
In the overall solution however, 'Navigation' (cross
references) must be able to (via the end user) close the
loop the sitemap has opened: Sitemap points from URI to
content.  Content wants to link back to URI.
</snip>

> Now, we have seen that users like a (possibly) 1-1
> mapping between dir
> layout and URI space, and I agree with it.

it is mapping how they structure their content on hard disk, it
probably reflects how it can be addressed in the URI space as
well.
there is surely arguments for not having it totally and fully
1-1, but there is sure arguments about not needing to turn around
everything.

> The point is, how do we know what pipeline to match
> against when
> generating the content?
>
> Marc, now I get your point :-D
>

at least one of them :-)

> ie
>
>    myfile.pipeline.extension
>
> I like it.
>
> >>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...
>
> There is an action that sees if a resource exists.
>
> When I ask for
>
>    myfile.pdf
>
> it can see if it finds
>
>    myfile.pdf
>
> and serve it.
> If not it would do:
>
>    /myfile.xml
>
> calling the gen pdf pipeline.
>
> I prefer the previous.
>

jap, I see it working now...
second request for the same would find it then?
would break a bit of the flow we have going, no?

little difference to just let cocoon 'read' all *.pdf
and have them generated on beforehand by style  and fo tasks?

-marc=


Mime
View raw message