Brett Sanger wrote:
> The problem here is that this is purely a display function. I can write
> a plugin to do the work if needs be, but I don't want to move the code
> to the production side.
How about re-writing the sort/nsort list vmethods to accept multiple
search criteria? That would probably be the most generically useful
solution (but perhaps also the most difficult).
[% list.sort('year', 'month') %]
Or add your own "datewise" vmethod (perhaps loaded via a plugin) which
sorts them according to your pre-defined criteria.
[% list.datewise %]
That would be my general strategy when you have something that belongs
in the presentation layer, but warrants the use of Perl code: write a
plugin, filter, or vmethod that does it for you in the "background".
If you're going down this route, then you might also like to consider
further abstracting the methods to hide the implementation details.
For example:
[% USE MyOrg %] # loads various useful vmethods, etc.
[% FOREACH product IN products.most_popular %]
...
[% END %]
The "most_popular" vmethod might return the best selling products,
or the products most recently sold, or those that the company is trying
to promote this week. By encoding this kind of decision in a plugin, you
keep the logic (albeit a mix of presentation and perhaps also business
logic) in one place, rather than dotting around a bunch of different
templates. It also makes the templates clearer, more clearly showing
the intent of the operation, rather than the messy details.
You don't have to use vmethods, of course. You could just as easily
write plugin methods:
[% USE pc = MyOrg.ProductChooser %]
# get the ten best selling products
[% FOREACH product IN pc.best_selling(products, 10) %]
...
[% END %]
# get the ten most recent products
[% FOREACH product IN pc.most_recent(products, 10) %]
...
[% END %]
HTH
A
_______________________________________________
templates mailing list
[EMAIL PROTECTED]
http://lists.template-toolkit.org/mailman/listinfo/templates
