Re: template path problems

[Tim Janik <timj gtk org>]

On Fri, 9 May 2003, Alper Ersoy wrote:

> Tim Janik:
> > > Well xslt templates can already handle multiple directories, IIRC, ie.
> > > a file in /cgi-bin/ can use the stylesheet and images in ../html/ if
> > > the correct prefix is supplied (in the browser's point of view, like
> > > ../, but that's just a detail ;)
>
> > eh? how do the templates know what directory a file lives in?
>
> They accept parameters for them, ie. --images=../cvs-images if you are
> using texitheque :)  Well, templates are not intelligent, but at least
> they can be taught how to behave.
>
> > hm, you want the templates to sit in the cgi-bin/ dir as well?
>
> Yes, I don't see a problem with that, ie. a script having its template
> with itself.

well, i'd rather keep that stuff seperated, i.e. scripts in cgi-bin and
keep the html files elsewhere.

> > what makes me wonder is that you don't have a --prefix or similar argument
> > to texitheque here, so how would it figure it's got to translate your paths?
>
> We initially decided that html files won't end up in sub directories,
> so it will only prepend '../' (for cgi-bin).  It's not an issue
> though, to change this (to add a new parameter).

yep, that not using sub-dirs broke with cgi-bin however, which is why i
keep talking about letting the xsl stylesheets know about directory
prefixes of the html pages. maybe i should have made that mroe clear...

> > but anyway, making a few slight modifications to your suggestion:
> > - we add @htmlprefix{} to our macros, and add to our template sources:
> >   @htmlprefix{cgi-bin/} so the xslts know the final basepath
>
> Hm, no, we can't do that.  We have to use ../ instead of cgi-bin/
> because files do not need to know where they end up, but they need to
> know where stylesheets and images ended up (in a browser's point of
> view, since the requests will be made by a browser).

well ok, i was thinking along a different line there, but ../ may be
better, so make that:
- we add @htmlbase{} to our macros, and add to our template sources:
  @htmlbase{../} so the xslts know the final basepath


> > - we add @cgitemplate to the macro set that just generates "\n@CGITEMPLATE@\n"
> >   in the html output, which is good enough to be matched by a perl script.
> > - the template file names are hard coded in the cgi scripts,
> >   e.g. ../browse.html, they just cat and susbtitute @CGITEMPLATE@  if
> >   that's there.
>
> I was planning to use $0 for template names.  So you can use the same
> script (ie. gallery) for two different pages (ie. logo-submissions vs.
> screenshots).
>
> In httpd.conf:
>   ScriptAlias /cgi-bin/logo-submissions /web/beast/cgi-bin/gallery

we shouldn't rely on more httpd.conf changes, it's not like we
couldn't get by without and using it doesn't buy us anything really.

i don't like the idea of going just by the name, since you'll
most probably need more flexibility soon. e.g. if logo submissions
should do different paging than screenshots etc.
i think there's a problem in the first place even, to get the scripts
to know about the sub directory that the images reside in (going through
the ScriptAlias like you sugegst above is not a good solution, e.g. it
requires httpd.conf changes for every new gallery you open)
so, suppose we have gallery.cgi *seomehere* (prolly in texitheque) that
implements the basic browsing facilities, we should do one of:
- have logo.cgi in cgi-bin/ that is mostly a copy of gallery.cgi plus
  some additional IMAGE_ROOT=/foo/bar/images/ config variables, the
  same with screenshots.cgi just using a different path
- have logo.cgi and screenshots.cgi contain *only* the config stuff and
  then call gallery.cgi which should sit in another directoy (just so that
  people can't point at cgi-bin/gallery.cgi directly)

> > that way, we don't need any extra rules, there're no non-scripts cluttering
> > up the cgi-bin/ dir, and the html files effectively being browsed as
> > cgi-bin/* is taken care of by xslt magic based on @htmlprefix{}.
>
> Let me try how things will work in practice tonight.

> --
> Alper Ersoy
>

---
ciaoTJ