On 7/5/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
Do you avoid macros because the localization hit or because of the
namespace issues?

I avoid them because it's too confusing for me and the reasoning about
which one to use is too hard for me to explain to designers.  I just
stick with PROCESS.  I'm a TT2 luddite, really.

Thousands, for sure.  A small handful can really help.  It's not so
much to do something better done in Perl, but as a way to avoid
writing the same markup over and over.  A real plus when you want to
change a common page element on the entire site sometime down the
road.

Sure, header, footer, navbar, etc.  I'd have those with any SSI or
template thing.

WRAPPERs are the biggest gem for getting out of that top-down approach
to page design that lends itself to markup duplication.

I resisted those for a long time, but I think I might try them next time.

Likewise, a few macros can help.  Abstracting out common elements is
useful in Templates as it is elsewhere in the code you write.

DRY is a nice principle, but too much focus on it leads to crazy
templates.  I've seen it happen.  I try not to worry too much about a
little duplicated markup.

Say you have a site with a large number of tables and they all should
look similar.

Each table has click-able headings and displays a page of rows with
alternating even/odd-style, and pager links (Previous 1 2 3 4 Next).

That's a pretty complicated widget with deep ties to backend
functions.  I'd probably do some special thing for that, making it a
high-level widget with code and templates separate from the rest of
the page content.

Your MACRO use sounds reasonable.  It's all about balance.  Having
seen a lot of templates that were not maintainable because of
over-DRYing, I'm pretty cautious about this kind of thing.

- Perrin

_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/

Reply via email to