Ok, first at all you do have secondary templates in your approach - just to
make clear how I used terms:

* your primary template is the one with slots
* your secondary template is the one which uses primary one and replaces

*p.s. please do not argue on usage of terms, lets just assume what is
primary/secondary ones and in these terms*
*my thoughts in previous email applies.*

Then, with approach you proposed - it seems like you cannot reuse your
secondary templates in different primary templates.
For example, what if you have main html layout (rendering your website
opened in browser tab), and then popup layout which
has simplified view (with less sections, and maybe with "close this popup"
button applied). Then you can display the same page
in the full normal view, or with minimal components in popup view. But if
you are hardcoding template inheritance, you are not able to do so.

Here is another approach that is widely used (I think so):

xhtml.xml - defines xhtml template with body, tags etc, expects layout and
page variables to be passed
layout-full.xml - defines html layout for the normal site view and calls
"page" macro in it;
layout-popup.xml - defines html layout for popups and calls "page" macro in
it, again.

This way you can reuse the same bind the same page contents to different
html layouts,
and if you use slots for this approach - you will have to make your final
"page" templates to be aware about
what slots are declared in primary templates.

As a conclusion, it looks like using slots is like mutable programming,
while using macro is more like immutable one
in terms of that with using macro your macro must not know anything about
environment from where it's used,
while with slots it must do - and that makes it less separated and reusable.
Eg, in order to use your secondary (final, or page)
template in primary template, you have to design your primary template as
expected by all secondary templates used with it,
which is not right.

So my bid is still against slots.

But I'm very (VERY!) interested to see an example where slots are better.
Just had no chance to find such usage yet.

Regards,

Anton Andriyevskyy
Business Automation & Web Development



On Mon, Jul 11, 2011 at 11:41 AM, Marco Pivetta <ocram...@gmail.com> wrote:

> 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
>
>
_______________________________________________
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal

Reply via email to