Re: template path problems

[Tim Janik <timj gtk org>]

On Fri, 9 May 2003, Alper Ersoy wrote:

> Tim Janik:
> > i thought about the html template and cgi script problem
> > some more, and while it'd be good to change xslt stuff
> > towards supporting multiple directories, we can handle
> > the problem at hand with an IMHO better solution.
>
> 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?

> My biggest concern is the transfer of HTTP variables.  It may me easy
> to handle a directory name to be browsed, but when it comes to file
> uploading that may turn out to be tricky business, because PHP will
> automatically try to handle tmp files, etc. to help us.
>
> I'm in favor of something similar though...  You write a template
> file, with this somewhere in the middle:
>
> __BODY__  (or something else, __CGIHOOK__ maybe?
>            A text like __TWIN_PEAKS_:_FIRE_WALK_WITH_ME is guaranteed
>            to not mix with regular text.)
>
> When a file in cgi-bin is accessed, it checks for $0.template, and
> substitutes __CGIHOOK__ with the content it generates.

hm, you want the templates to sit in the cgi-bin/ dir as well?

> This is much like the initial suggestion you made about the templates.
>
> List of changes needed in beast/docs/generated/Makefile.am:
>
>   - %.template rule:
>
> XML2TMPL=texitheque xml2template
> %.template: %.xml
> 	$(XML2TMPL) --output=$@ --images="cvs-images/" \
> 		--banner="beast" --icon="beast16.png"
>
> (This rule is same with %.html, except XML2TMPL instead of XML2HTML.)

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?

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

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

> (When I'm done with the CGI versions of scripts in /web/beast/dyn/,
> site-update-nav will be obsolete [/web/beast/dyn will be obsolete
> too], so site-update-cgi is not an extra.)

that sounds cool, how are you going to do that? replace both scanfiles.pl
and scanpics.pl with dynamic content generation scripts?

> --
> Alper Ersoy
>

---
ciaoTJ