[Maypole] Re: Maypole responding to requests very slowly (or, how to get just one associated record instead of getting the world)

[Simon Flack]

David Baird wrote:
> 
> 
> Simon Flack wrote:
> 
>> Peter Speltz wrote:
>>
>>> I was thinking in the view::base where "IT" is created of doing 
>>> something like
>>> this:
>>>
>>>     . . .
>>>     cgi => $r->template_args{classmetadata_cgi} || { $class->to_cgi }
>>>     . . .
>>>
>>> Then the model's sub can make them if it wants or set it to "1" to 
>>> get none or
>>> do nothing and get them.
>>
>>
>>
>> That looks good. But I'm not sure that it should be controlled by a 
>> template parameter. I was going to suggest something in $r->config, 
>> but that doesn't smell quite right either.
>>
>> Perhaps it's something that you define on a class-by-class basis. Or 
>> perhaps you want different behaviour for different actions in a model?
>>
>> I'd be tempted to change it to:
>>
>>      cgi => sub { $class->to_cgi() },
>> or
>>      cgi => sub { $class->to_field(@_) },
>>
>> That should work quite nicely for M::V::TT - there's no overhead 
>> unless you actually use it in the template. I imagine you'd need a 
>> different solution for Mason though.
> 
> 
> Mason templates are just Perl, so you would say
> 
>     $classmetadata->{cgi}->()
> 
> instead of
> 
>     $classmetadata->{cgi}
> 
> Out of interest, how does the call look in TT - is it the same for both 
> cases?

In the first instance, it'd be something like:

	[% classmetadata.cgi.field_name %]

but if you're calling that multiple times in the same template, you'd 
want to assign classmetadata.cgi to a temporary variable to avoid 
creating all the html elements every time:

	[% elements = classmetadata.cgi %]
	[% elements.field_name %]
	[% elements.another_field %]

The second option, would look like this:

	[% classmetadata.cgi('field_name') %]

and wouldn't need a temporary variable.

But both of these approaches change the current behaviour - the first 
option keeps the same syntax, but is very expensive if you forget to 
assign it to a variable. But there may be a way of optimising it in TT, 
or memoizing the function.

--simonflk