On Jan 21, 2008, at 10:49 PM, mike wrote:
On Jan 21, 2008 11:04 AM, Andy Wardley <[EMAIL PROTECTED]> wrote:
mike wrote:
however, it appears that TT3 has not been touched in over two
years.
Hi Mike,
Actually, it's more the case the the TT3 web site hasn't been touched
in over two years. I _have_ been touching TT3 in that time (honest!)
although not as much as I would have liked due to commitments to
various projects for other people.
mmmhmmm, suuuure. :)
However, my work schedule is now relatively clear so I'm doing a fair
bit of TT3 touching right now. I'm hoping this will be the last
burst
to get it out the door in the next few months.
i look forward to it.
rather than wait for TT3, i am proffering the attached unintrusive
patch to satiate those (such as myself) whom are suffering from
moderate to severe insanity arising from the use of template
toolkit and code that uses wantarray.
Count me among those people. It's probably of little consolation,
but
I kick myself hard every time I get bitten by it. Consider me
suitably punished.
honestly, i don't believe it to be TT's fault. the blame lies
squarely
with DBIx::Class. i loathe wantarray and DBIx::Class's liberal use of
it. those of you familiar with DBIx::Class may know that relationship
accessors or the ResultSet->search method will "optimize" for you by
assuming that you want a list of objects (as would be returned by the
ResultSet->all method) if called in list context. while this may
typically be the case, it is not always so. this "optimization" robs
the user of flexibility and control in exchange for not having to type
->all when you really mean it. in this case, DWIM fails to DTRT.
Yes wantarray is annoying. But oh look, its almost as if DBIx::Class
users use TT to. I point you at search_rs:
From DBIx::Class::Resultset:
This method does the same exact thing as search() except it will
always return a resultset, even in list context.
From DBIx::Class::Relationship:
Three methods are created when you create a has_many relationship.
The first
method is the expected accessor method, C<$accessor_name()>. The
second is
almost exactly the same as the accessor method but "_rs" is added to
the end of
the method name. This method works just like the normal accessor,
except that
it returns a resultset no matter what, even in list context. The third
method,
named C<< add_to_$relname >>, will also be added to your Row items; this
allows you to insert new related items, using the same mechanism as in
L<DBIx::Class::Relationship::Base/"create_related">.
These features have been in DBIx::Class since about mid-2006.
[snip]
your solution is quite elegant; i worried though about the potential
performance implications of instantiating a new object for each call.
take, for instance, a ResultSet chain i am currently using in a
category
listing template:
[%
category
.call_method_scalar('products').call_method_scalar('search_related',
'authorizations
').call_method_scalar
('magazine
').call_method_scalar('trade').call_method_scalar('collecting').count
%]
[% category.products_rs.search_related_rs('authorizations').
magazine_rs.trade_rs.collecting_rs.count %]
Should do the same job.
For future reference, the DBIx::Class mailing list is at
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
[more reply snipped]
_______________________________________________
templates mailing list
templates@template-toolkit.org
http://mail.template-toolkit.org/mailman/listinfo/templates
