Re: template path problems

[Alper Ersoy <dirt gtk org>]

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

> the idea is to use something like:
> @phpexec{/web/beast/cgi-bin/fbrowser#/, Resource available at:
> http://beast.gtk.org/contrib.phtml} in the texi files. that requires
> additional (minor) modifications to our build process:
> - html.xsl needs to support @phpexec{execcmd,substitute} by
>   outputting <?php system(execcmd)...
> - docs/generated/Makefile.am needs to generate phtml files from some
>   sources
> - *.xsl should support @phpexec{execcmd,substitute} by outputting:
>   substitute
> - html.xsl should issue a warning if non-phtml is generated and uses
>   @phpexec{} (whishlist item, i think html.xsl does not currently
>   know whether the output is redirected to >*.html or >*.phtml, thus
>   we can defer this until moving stuff to texitheque, which can
>   easily provide additional info for html.xsl)

It's extra load to first run the PHP interpreter and then throwing it
away in favor of Perl (or something else).  Sounds like an overkill to
use PHP just for that.

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.

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

Texitheque will then handle prefixing '../' etc., so the templates
work inside /cgi-bin/.

  - template_targets = $(strip
	browse.template
	gallery.template
	upload.template
    )

  - Another prerequisite for site rule: $(template_targets)
    
    And another tar entry in site rule:
	tar jcf beast-site-cgi.tar.bz2 --mode=0664 $(template_targets)

  - A site-update-cgi rule that extracts beast-site-cgi.tar.bz2 to
    /web/beast/cgi-bin/

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

What do you think about this approach?

-- 
Alper Ersoy