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