[Zope] Page Templates are great, but...

[KevinL]

On Mon, 2002-06-03 at 05:11, Evan Simpson wrote:
> KevinL wrote:
> > There seems to be two ways to manage this stuff.  Metal is great, but
> > will push you into building "well-formed" modules - so instead of
> > standard_header and standard_footer, you build a standard_page macro,
> > which contains both, and feed your content into that.  It's a bit wierd,
> > but it works well.
> 
> Please realize that this use of METAL, while a fairly effective way to 
> implement uniform page layouts, is not its primary use!  This often 
> seems to be lost on newcomers to ZPT, whose first exposure to METAL is 
> this rather advanced and complex case.

I think that's because it's the first thing you want to do.

Particularly, migrating from dtml to ptl, the first thing I need to do
is take standard_html_header and _footer (and indeed, that whole mindset
of "here's where we define a common look/layout for the pages"), and
convert them to ptl.

I reckon what you're considering as an "advanced and complex case" is
actually about the first thing most people need to figure out how to do.
Otherwise, you're right back in "build the structure of each page into
each page", which is boring and tedious and hard to work with.

Am I making sense?  Our particular application went one step further,
and used slots for primary_content, help_text, error_message, and a few
other things - which made site design _so_ much easier (and meant us
non-html-coders could throw basic pages up without having to bug the
html people ;)

>    <div id="copyright" metal:define-macro="copyright">
>      This page &copy;2002 Foobly Enterprises LLC, all rights reserved.
>    </div>
> 
> Now you reuse it in other pages with:
> 
>    <div metal:use-macro="here/index_html/macros/copyright"></div>
> 
> No slots or other complications needed.  Any TAL in the macro is 
> executed as though it were part of the page that's using it, so you 
> don't need to worry about passing parameters, or losing context, or any 
> of the difficulties introduced by calling one template from another.  An 
> addition advantage over <span tal:replace="structure here/zpt_snippet"> 
> is that a single page can define any number of independent macros.

I have no use for this, because I can already do it by calling via
tal:replace - and I prefer tal:replace, because it allows me to keep
each snippet in a separate file, inside a common folder - which to my
mind is far better(tm) than having to declare all those snippets in a
single file.  And, what's more, tal naming is easier to explain to
non-coders - adding the /macros/macro_name, as simple as it is, is a
common source of initial confusion/error on behalf of the html people. 
They understand "refer to that page in that folder", they don't
understand "refer to the macro name in the "macros" namespace of that
page in that folder".

YMMV,
KevinL