Re: [PHPTAL] How slots are better then macro?
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: >> >> >> >> >> >> >> >> >> >> 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 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: >> >> >> >> >> >> >> >> >> >> >> >> >> >> 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 >> 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
Re: [PHPTAL] How slots are better then macro?
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: > > > > > > > > > > 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 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: > > > > > > > > > > > > > > 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 > 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
Re: [PHPTAL] How slots are better then macro?
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: 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 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: 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 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
Re: [PHPTAL] How slots are better then macro?
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
Re: [PHPTAL] How slots are better then macro?
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' => '', 'var2' => ''));
$site->setSlot('banner1', $stuff);
$site->setSlot('banner2', $stuff2);
$site->setSlot('layout', $portrait);
echo $site;
$content = new ContentTemplate();
$email = new EmailTemplate(array( 'var1' => '', 'var2' => ''));
$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 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 wrote:
>
>> The 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 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 (,
>>> and , 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:
>
Re: [PHPTAL] How slots are better then macro?
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 wrote:
> The 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 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 (,
>> and , 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:
>>
>> > xmlns="http://www.w3.org/1999/xhtml";
>> xml:lang="${php:isset(lang) ? lang : 'en'}"
>> lang="${php:isset(lang) ? lang : 'en'}"
>> >
>>
>>
>>
>> > metal:use-macro="templates/xhtml/head.xml/head"/>
>>
>>
>>
>>
>>
>>
>> > metal:use-macro="templates/xhtml/body.xml/body"/>
>>
>>
>>
>>
>>
>> user-profile.xml - my view, calls template and does stuff in it - replaces
>> body completely:
>>
>> > XHTML+RDFa
>> 1.0//EN""http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd";>
>>
>>
>>
>>
>>
>> mailto:${user/email}"; tal:content="user/email"/>
>>
>>
>>
>>
>>
>> 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:
>>
>>
>>
>>
>> Login:
>>
>>
>>
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:
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 wit
Re: [PHPTAL] How slots are better then macro?
The 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 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 (,
> and , 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:
>
> xmlns="http://www.w3.org/1999/xhtml";
> xml:lang="${php:isset(lang) ? lang : 'en'}"
> lang="${php:isset(lang) ? lang : 'en'}"
> >
>
>
>
> metal:use-macro="templates/xhtml/head.xml/head"/>
>
>
>
>
>
>
> metal:use-macro="templates/xhtml/body.xml/body"/>
>
>
>
>
>
> user-profile.xml - my view, calls template and does stuff in it - replaces
> body completely:
>
> XHTML+RDFa
> 1.0//EN""http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd";>
>
>
>
>
>
> mailto:${user/email}"; tal:content="user/email"/>
>
>
>
>
>
> 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:
>
>
>
>
> Login:
>
>
>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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:
>>>
>>>
>>>
>>>
>>> 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 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 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
Re: [PHPTAL] How slots are better then macro?
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 (,
and , 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:
http://www.w3.org/1999/xhtml";
xml:lang="${php:isset(lang) ? lang : 'en'}"
lang="${php:isset(lang) ? lang : 'en'}"
>
user-profile.xml - my view, calls template and does stuff in it - replaces
body completely:
http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd";>
mailto:${user/email}"; tal:content="user/email"/>
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:
Login:
>>
>>
>>
>>
>>
>>
>> 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:
>>
>>
>>
>>
>> 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 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 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
Re: [PHPTAL] How slots are better then macro?
>> 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 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: > > > > > > > > > > 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: > > > > > 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 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 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
Re: [PHPTAL] How slots are better then macro?
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: 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: 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 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 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
Re: [PHPTAL] How slots are better then macro?
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 wrote: > Marco ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
Re: [PHPTAL] How slots are better then macro?
siteheader.xml template file: Some example text Actual file rendered: Debug Messages: As you can see, the slot is used to combine replace a piece of my template at runtime... Marco Pivetta http://twitter.com/Ocramius http://marco-pivetta.com On 11 July 2011 09:10, Anton Andriyevskyy wrote: > I still do not understand when and why to use slots, > I always use macro. > > Can anyone show me a meaningful and useful example demonstrating when slots > are better then macro? > > Regards, > > Anton Andriyevskyy > Business Automation & Web Development > > > ___ > 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] How slots are better then macro?
I still do not understand when and why to use slots, I always use macro. Can anyone show me a meaningful and useful example demonstrating when slots are better then macro? Regards, Anton Andriyevskyy Business Automation & Web Development ___ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
