[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
Re: [PHPTAL] How slots are better then macro?
siteheader.xml template file: div metal:define-macro=siteheader id=header tal:block metal:define-slot=debug/ pSome example text/p img src=stuff.png alt=stuff/ /div Actual file rendered: tal:block metal:use-macro=siteheader.xml/siteheader p metal:fill-slot=debug class=debug tal:condition=user/is_admin Debug Messages: br/ tal:block tal:content=debug_log/ /p /tal:block 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 x.meg...@gmail.com 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
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 ocram...@gmail.com 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?
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.comwrote: 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?
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.comwrote: 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?
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//ENhttp://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
h1Login:/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.comwrote:
Suppose that you wrote a complex template...
It has a header, footer, sidebars, h1, site logo...
Re: [PHPTAL] How slots are better then macro?
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//ENhttp://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
h1Login:/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
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 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//ENhttp://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
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 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.comwrote:
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
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?
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
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:
!-- 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
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:
!-- 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
