[Zope] Uses of METAL?

[Tino Wildenhain]

Hi Alec,

--On Montag, 4. November 2002 10:17 -0400 Alec Munro 
<alecmunro@hfx.eastlink.ca> wrote:

> Felix Ulrich-Oltean wrote:
>
>> On Mon, Nov 04, 2002 at 09:37:30AM -0400, Alec Munro wrote:
>>
>>
>>> How are other people using METAL in serious applications? I would
>>> love to hear how it is being used by those more familiar with Zope
>>> than myself.  Thanks very much,
>>>
>>>
>>
>> The main thing we use macros for is to define an overall "master page"
>> with the general layout of pages in a site, including default bits
>> which are wrapped in metal:define-slot, to allow client[1] templates to
>> customize those bits.  Most templates/pages in the sites are then
>> something like this:
>>
>> <html metal:use-macro="container/master_page.html/macros/page">
>>
>>  <metal:block metal:fill-slot="">
>>
>>    Some really <b>fancy</b>content.
>>
>>  </metal:block>
>>
>> </html>
>>
>> I know you can use tal and still have components and wel--structured
>> sites, but in my short experience, it seems that using METAL gives you
>> more power in the actual client[1] templates, whereas with TAL alone
>> I seemed to pull in a lot of things into a "main" template, taking
>> power away from the specialized templates.
>>
>>
>> 1 - "client" - by client templates I mean a template that uses the
>> template with macros in, i.e. the client template is either applied to
>> the called object, or IS the called object.
>>
>> Felix.
>>
>>
>>
>>
>>
> Actually, I have implemented slots in TAL, in a way (Though I do have a
> tendency to call TAL ZPT). I create a template, and I give it areas that
> it fills from session variables, and I use python scripts to manipulate
> those session variables. This gives me programmatic control over
> navigation, though I do find it gets a little complex at times.
> Basically, I have templates that look like this:
> <html>
>  <body>
>  <span tal:replace="structure
> python:container.restrictedTraverse(request.SESSION['current_page'])()"><
> /span>  </body>
> </html>
>
> All my anchors point to python scripts, which load the appropriate
> templates into Session variables, and then return the current default
> template. I would love to discuss what METAL can offer me over this,
> because as I said, it does get complex. Thanks for the response,
> Alec Munro

Hm. I think this is the oposite of what ZPT is intended ;)
The most important idea behind ZPT is to have always a complete HTML page.
So TAL comes in and helps you to modify attributes and content of HTML tags
in this otherwise ready to view page.
If you go that way you will find out in an average site you'll end up
having many pages with identical parts, for example a site wide
navigation or even some static elements.
There METAL comes in and lets you define a page wich has all typical 
elements
which are common to all pages. All the parts that are specific to a page
are enclosed in metal:define-slot. Think of such a master-page like
a template with holes where your client page looks thru.

The master page would use TAL for dynamic parts the same way like the
client page does.

The only drawback of METAL is you cannot have something like a class 
hierarchy,
say main-template -> common-template-for-some-pages -> 
individiual-client-page

Currently I'm using a construct like a main-template with define-macro 
parts,
some common-for-some-pages templates which are assembled with macros from 
main-template
and define themself as one whole macro, the actual client templates use 
this assembled
template as master. This allows to archieve the main goal: dont duplicate
parts of content/logic. Every part can be changed in only one place and 
changes
will populate thru the whole site where this part is used.

HTH
Tino Wildenhain