Didn't really unserstand where "with using macro your macro must not know
anything about environment" goes:
If you currently work with switching template behavior then your template
knows about environment (variables passed in). They ARE the environment :|

With macros I slice my template logic in micro-pieces (much like java server
facelets) that I can reuse anywhere.
Functionality is limited compared with facelets, but here's how I'd simplify
the differences between macro only and slots:
*
"each template accepts vars" equivalent:*

echo do_site(array( 'banner1' => 'stuff', 'banner2' => 'stuff2', 'layout' =>
'portrait'));

echo do_email(array( 'main_image' => 'someimage', 'content' => 'blahblah'));

*
"slots" equivalent:*

$stuff = new StuffTemplate();
$stuff2 = new Stuff2Template();
$portrait = new PortraitTemplate();
$site = new SiteTemplate(array( 'var1' => 'aaaa', 'var2' => 'bbbb'));
$site->setSlot('banner1', $stuff);
$site->setSlot('banner2', $stuff2);
$site->setSlot('layout', $portrait);
echo $site;

$content = new ContentTemplate();
$email = new EmailTemplate(array( 'var1' => 'aaaa', 'var2' => 'bbbb'));
$email->setSlot('main_image', 'someimage');
$email->setSlot('content', $content);
echo $email;

I prefer the second much more because it ALSO allows the usage of variables
and encourages (imho) something that looks similar to a Decorator OOP
pattern...
Can't help with it much more, probably because of my capacity of explaining
my idea or probably because of a language limit... Anyway, hope it was
useful anyway :) So stopping with my delirium and letting others put their
opinion here :)

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



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

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

Reply via email to