The <head/> replacement in the template above is obviously an overkill as it
is a required xhtml element, but I hope it renders the idea of being able to
replace stuff at precise spots :)
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com



On 11 July 2011 10:37, Marco Pivetta <ocram...@gmail.com> wrote:

> 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