On Thu, Jul 05, 2007 at 11:15:57AM -0400, Perrin Harkins wrote: > For those out there who like TT2's mini-language, I've been using it > for many years without ever encountering any of the problems described > in this thread. I never add any variables to the stash from inside my > templates (temporary loop variables excluded), avoid MACRO (I only use > PROCESS), and generally keep the templates very, very simple. And I > have documentation that describes the data structure that will be in > the stash for each page.
Do you avoid macros because the localization hit or because of the namespace issues? I don't normally have that many items in the stash (or macros) so namespace collision is not a concern. > Templates aren't normal code (even with in-line perl) and they don't > handle complexity like real code does, so you have to control your > impulse to turn them into thousands of little components. It just > gets too confusing. 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. WRAPPERs are the biggest gem for getting out of that top-down approach to page design that lends itself to markup duplication. WRAPPERs can be confusing at first, but they are not that hard to get used to. Likewise, a few macros can help. Abstracting out common elements is useful in Templates as it is elsewhere in the code you write. 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). Those are all display items -- belongs in the View. How would you generate the <th> links that show which is the currently sorted column and an indicator if it's sorted ascending or descending? Obviously, that code should only be done once. I just want to be concerned with the data that's unique for the page I'm generating. So, for the <th> example, I set up a block like this where the table_headings_link() macro adds in all the markup for creating the click-able headings and creates the correct self-reference URL (as the table might already be limited by, say, a query string). [% BLOCK table_headings %] <tr> <th> [% table_heading_link( 'Name', 'name', ) %]<br /> [% table_heading_link( 'Account', 'account', ) %] </th> <th> [% table_heading_link( 'Email', 'email', ) %] </th> <th> Status [% table_heading_link( 'Active', 'active' ) %] / [% table_heading_link( 'Admin', 'admin' ) %] </th> </tr> [% END %] You could do this: <th> [% PROCESS table_heading_link label = 'Name', sortby = 'name'; '<br />'; PROCESS table_heading_link label = 'Account', sortby = 'account'; %] </th> But I think the macros help with readability. In the past I've abstracted that out even more (since the <tr> and <th> is common on every page -- but that's a bit overkill. -- Bill Moseley [EMAIL PROTECTED] _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/