Sorry about that, just like this example alot.

On 07/11/11 21:48, Levi Stanley wrote:
> 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


_______________________________________________
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal

Reply via email to