>> 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
