[Templates] [PATCH] allow forcing scalar context to deal with ornery object methods

[Ash Berlin]

On Jan 21, 2008, at 10:49 PM, mike wrote:

> On Jan 21, 2008 11:04 AM, Andy Wardley <abw at wardley.org> 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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.template-toolkit.org/pipermail/templates/attachments/20080122/fb131be0/attachment-0001.htm