1) I usually don't have secundary templates. Or at least, this happens
rarely, like when differentiating emails from website xhtml. I prefer having
small and clean templates that use the smallest possible number of
variables. Supposing I write a "xhtml wrapper" template that accepts some
content and handles basic stuff like placing required tags (<html/>, <head/>
and <body/>, DTD, namespace), that template should handle and be aware ONLY
of those vars:

templates/xhtml.xml - xhtml wrapper, we'll inject body in here or use the
standard one:
<tal:block metal:define-slot="dtd"><!DOCTYPE html></tal:block> <!-- allows
DTD replacement -->
<xhtml
    xmlns="http://www.w3.org/1999/xhtml";
    xml:lang="${php:isset(lang) ? lang : 'en'}"
    lang="${php:isset(lang) ? lang : 'en'}"
>
    <tal:block metal:define-slot="head"> <!-- allows <head/> replacement -->
        <head>
            <tal:block metal:define-slot="head-content"> <!-- allows <head/>
content replacement -->
                 <tal:block
metal:use-macro="templates/xhtml/head.xml/head"/> <!-- calling the default
<head/>, used when I don't need particular customization or replace pieces
only within the default <head/> -->
            </tal:block>
        </head>
    </tal:block>
    <tal:block metal:define-slot="body"> <!-- allows <body/> replacement -->
        <body>
            <tal:block metal:define-slot="body-content"> <!-- allows <body/>
content replacement -->
                 <tal:block
metal:use-macro="templates/xhtml/body.xml/body"/> <!-- calling the default
<body/>, used when I don't need particular customization or replace pieces
only within the default <body/> -->
            </tal:block>
        </body>
    </tal:block>
</xhtml>

user-profile.xml - my view, calls template and does stuff in it - replaces
body completely:
<tal:block metal:use-macro="templates/xhtml.xml">
    <tal:block metal:fill-slot="dtd"><!DOCTYPE html PUBLIC "-//W3C//DTD
XHTML+RDFa 1.0//EN""http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd";></tal:block>
<!-- need RDFA when displaying a user profile (example, not appying here)
-->
    <tal:block metal:fill-slot="body-content">
        <div id="article">
            <h1 tal:content="user/fullname"/>
            <p tal:content="user/bio"/>
            <a href="mailto:${user/email}"; tal:content="user/email"/>
            <!-- etc... -->
        </div>
    </tal:block>
</tal:block>

This is an example... I usually nest more (i18n ignored here):

login.xml - my view, calls template and does stuff in it - replaces body
partially:
<tal:block metal:use-macro="templates/xhtml.xml">
    <tal:block metal:fill-slot="body-content">
        <tal:block metal:use-macro="templates/xhtml/body.xml/body"> <!--
this nesting could be omitted, but I prefer keeping it avoids troubles with
duplicate slot names -->
            <tal:block metal:fill-slot="article-title">
                <h1>Login:</h1>
            </tal:block>
            <tal:block metal:fill-slot="article-content">
                <!-- I usually do this with form objects. Copying for
clearness
                <form method="post" action="/login">
                    <input type="text" name="login" placeholder="Username"/>
                    <input type="password" name="password"
placeholder="Password"/>
                    <input type="submit" value="Login"/>
                </form>
            </tal:block>
        </tal:block>
    </tal:block>
</tal:block>

This is how I usually work. Every template could be used singularly or could
use legacy default macro calls.
I could use my xhtml template in any project, won't be an issue :)

2) views are views, and the concept of "hardcoding" is quite different from
the one used in programming. A view is usually not part of the code flow. If
it is, then it probably isn't a view... I actually don't see any hardcoding
in the template above.

Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com



On 11 July 2011 10:07, Anton Andriyevskyy <x.meg...@gmail.com> wrote:

> >> The big advantage I personally see in this way of developing is that
> your template
> >> doesn't need to be aware of every variable that could be injected in it.
>
> ... but as for me this adds 2 disadvantages:
>
> 1) every secondary template that uses that main template must be aware of
> its slots;
> taking into account that we always have more secondary templates then
> primary templates,
> it's better to make primary templates to be aware of something, then to
> have secondary ones to do this.
>
> 2) this way you hardcode which primary template must be used to render your
> secondary template;
> of course you can still use variable macro name in metal:use-macro, and
> then define fill-slot,
> but this way you are limiting your primary templates to always define the
> same slots.
>
> So I'm still convinced that using slots is just a way to limit scalability
> of templates,
> and I'm very interested to see useful examples where slots are better then
> macro.
>
> Thanks,
>
> Anton Andriyevskyy
> Business Automation & Web Development
>
>
>
> On Mon, Jul 11, 2011 at 10:51 AM, Marco Pivetta <ocram...@gmail.com>wrote:
>
>> Suppose that you wrote a complex template...
>> It has a header, footer, sidebars, h1, site logo...
>>
>> Let's say you wish to have just 1 javascript or css added to your template
>> when visiting any page that relates, let's say, the user profile.
>>
>> Supposingthat you're using some standard MVC stack you'd probably have
>> something like a site.xml template and a user.xml:
>>
>> user.xml:
>> <tal:block metal:use-macro="templates/site.xml">
>>     <tal:block metal:fill-slot="additional-js">
>>        <!-- add your JS here! -->
>>     </tal:block>
>>     <tal:block metal:fill-slot="additional-css">
>>        <!-- add your CSS here -->
>>     </tal:block>
>> </tal:block>
>>
>> The big advantage I personally see in this way of developing is that your
>> template doesn't need to be aware of every variable that could be injected
>> in it. If you have specialized views, then those views should handle
>> variables and replace slots.
>> This makes your template independent from your app and also reusable, and
>> also less fragile and subject to bugs or VariableNotFound exceptions :)
>>
>> I often define dozens of slots and macros... Also if I don't use them,
>> like:
>> <div id="aside">
>>     <!-- stuff -->
>>     <tal:block metal:define-slot="banner"/>
>> </div>
>> This makes me life easier when I want to place a banner in that position
>> in future... I just have to generate the content somewhere else and then
>> stuff it in there with metal:fill-slot. No logic needed in the template. The
>> final view can handle that :)
>>
>>
>> Marco Pivetta
>> http://twitter.com/Ocramius
>> http://marco-pivetta.com
>>
>>
>>
>> On 11 July 2011 09:40, Anton Andriyevskyy <x.meg...@gmail.com> wrote:
>>
>>> Ok, Marco, so actually we are still continuing to use macro, but we make
>>> them more dynamic
>>> by defining slots, correct?
>>>
>>> Then still I have question how it's better then defining macro (instead
>>> of fill-slot) and call it
>>> with variable macro name inside template?
>>>
>>> Any thoughts?
>>>
>>> Anton Andriyevskyy
>>> Business Automation & Web Development
>>>
>>>
>>>
>>> On Mon, Jul 11, 2011 at 10:26 AM, Marco Pivetta <ocram...@gmail.com>wrote:
>>>
>>>> Marco
>>>
>>>
>>>
>>> _______________________________________________
>>> PHPTAL mailing list
>>> PHPTAL@lists.motion-twin.com
>>> http://lists.motion-twin.com/mailman/listinfo/phptal
>>>
>>>
>>
>> _______________________________________________
>> PHPTAL mailing list
>> PHPTAL@lists.motion-twin.com
>> http://lists.motion-twin.com/mailman/listinfo/phptal
>>
>>
>
> _______________________________________________
> PHPTAL mailing list
> PHPTAL@lists.motion-twin.com
> http://lists.motion-twin.com/mailman/listinfo/phptal
>
>
_______________________________________________
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal

Reply via email to