On 07/11/11 13:33, Darrell Hamilton wrote:
> We use slots as a way of implementing decorators in our templates.
> Often our designers use a similar wrapper of HTML around various
> pieces of content and we want them to be reusable.  There's actually
> two separate ways we could accomplish this feat.
>
> First, using only macros, we could simply pass the name of a macro
> containing the content, through tal:define, to the wrapper macro.
> That would look like so:
>
> <!-- Wrapper definition -->
> <tal:block metal:define-macro="wrapper">
>     <tal:block metal:use-macro="${content_macro | empty.html}/content" />
> </tal:block>
>
> <!-- Wrapper usage -->
> <tal:block metal:use-macro="wrapper" tal:define="content_macro
> ${variable_containing_macro_file}" />
>
> The usage of this form is more terse than the next form, but it has
> two issues.  The first, it's not very flexible.  You're only allowed a
> single macro to populate it with and every piece of content you want
> to put in this wrapper must be defined in a macro, which is kind of
> ridiculous if it's only a single <img /> you want to wrap.  The second
> is a conceptual issue.  A decorator/wrapper shouldn't be need to know
> how to evaluate its content, it should only care that, "I am a wrapper
> and here is my content".
>
> The alternative solution is to use a macro with a slot, like so:
>
> <!-- Wrapper definition -->
> <tal:block metal:define-macro="wrapper">
>     <tal:block metal:define-slot="content" />
> </tal:block>
>
> <!-- Wrapper usage -->
> <tal:block metal:use-macro="wrapper">
>     <tal:block metal:fill-slot="content">
>         <!-- Your Content Goes Here -->
>     </tal:block>
> </tal:block>
>
> The main downside to this approach is that using the wrapper takes a
> little bit more markup than the purely macro version.  The upsides to
> this approach are basically the opposites of the downsides to the
> previous approach.  Flexibility wise, you can put whatever you want
> into the wrapper, one macro, ten macros, static content, whatever.
> And, conceptually, it alleviates the issue of the wrapper needing to
> know how to evaluate its content.
>
> Darrell Hamilton,
> Software Developer,
> 4over, Inc
> darre...@4over.com
> 818-246-1170 ext. 285
>
>
>
> On Mon, Jul 11, 2011 at 8:37 AM, Fernando Martins <ferna...@cmartins.nl> 
> wrote:
>> On 07/11/2011 01:45 PM, Anton Andriyevskyy wrote:
>>> yes, I'm also interested in what others will say.
>>>
>>>
>> I quite don't understand why you compare macros against slots. Slots are
>> part of macros. It allows customisation of a macro.
>>
>> I use macros/slots the following way:
>>
>> - a main page template with all the common aspects of the web site (headers,
>> footers, navigation toolbar)
>> - this page template contains a few slots: e.g., one for the header and one
>> for a content area (a div)
>> - each (dynamic) page of the web site uses the main template and fills in
>> the slots as needed
>> - I have another special "page" which is merely a collection of macros that
>> I can reuse where needed. These macros might also have slots if needed.
>>
>> HTH,
>> Fernando
>>
>> _______________________________________________
>> 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