[Grok-dev] Re: How are viewlets better than macros?
d.w.morriss at gmail.com
Thu May 15 10:42:57 EDT 2008
Lennart Regebro wrote:
> On Mon, May 5, 2008 at 5:54 PM, Sebastian Ware <sebastian at urbantalk.se> wrote:
>> On the Grok site viewlets are explained to have "...basically the same
>> purpose as a macro, but is more clean, powerful and flexible." Only the text
>> fails to explain how. The example shown doesn't show much of this power or
>> flexibility as far as I can tell. Where is the real benefit? What am I
> Macros rely on global variables, but there is no way to see which
> variables they rely on, except reading the code very carefully. Macros
> are language dependent. Macros are difficult to override if you have
> more than one macro in a template.
> In short: Macros are evil. Do not use.
it's easy to use macros wrong and hurt yourself, but that doesn't make
them evil, just misunderstood. ;)
I think the distinction is more one of a hierarchy of concerns. from
macros (the least specific and structured) to viewlets (the most
specific and structured).
Macros work for simple reuse that requires only the most general
awareness of externalities(the calling template): reuse internal to a
template, or very general reuse like a maintemplate macro that calls
your more specific views, and contentproviders. If you need awareness
of the context, a view is good, of the context and the calling view,
contentproviders and viewlets.
Speed is another concern. On openplans, we used html snippet views for
alot things until we found we were paying a considerable rendering
penalty on the small stuff rendered inside loops w/ large numbers of
items. Inlining macros (or saving them to a reference within the
calling template) proved to be a significant win.
Macros are pretty easy to understand (define, use, slot) and read,
whereas introspection of the visual result of a bunch of viewlets or
view snippets can require introspection of the component registry. It
takes a while to wrap ones head around the benefits of 3 & 4 way
I think the key (as usual) is knowing when to use what, balancing
indirection against inflexibility.
More information about the Grok-dev