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

[Peter Speltz]

--- David Baird <dave@riverside-cms.co.uk> 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.
> > 

To me, since classmetadata is a template_arg essentially, so it would make
sense to override it in template_args. which is what you do now.  But you have
to do this currently and its all or nothing in the current View::Base
my $classmetadata = {}
$classmetadata->{cgi} = { col1 => ..., };
$classmetadata->{list_columns} = [ . . . ];
# Below wipes out all classmetadata except what's defined above.
$r->template_args->{classmetadata} = $classmetadata;  

It's obvious why that's undesireable to say the least. That's why i like the 
$r->{template_args}{TopLevel__NextLevel__YetAnotherLevel} method. Old code
still works but use $r->{template_args}{classmetadata__whatever} to override
individual vars made in View::Base and $r->{template_args}{TopLevel} to
override whole heirarchies.

NOTE: double underscore separate levels in hash.

> > 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?
> > 

Not sure what you mean. Each action sub can override whatever it wants. Say in
view, you don't want overhead of making cgi or list_columns say this:
sub view {
  ...
  $r->template_args{classmetadata__list_columns} = 1; 
  $r->template_args(classmetadata__cgi} = 1;

  .. .
}

Everything still backward compatible, just a handy optimization and more
powerful configuration of template_args. And template sys. independent.

> > I'd be tempted to change it to:
> > 
> >      cgi => sub { $class->to_cgi() },
> > or
> >      cgi => sub { $class->to_field(@_) },
> > 

This looks interesting.

> > 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?
> 

[% classmetadata.cgi.column %]
In TT objects, hashes, lists all use . operator to do their thing.

> Maybe the whole classmetadata thing should be an object?
> 

Can you give an example of how that would significantly improve things now? I
don't see how it would help but I wouldn't be surprised if it would. 

> d.
> 
> _______________________________________________
> maypole mailing list
> maypole@lists.netthink.co.uk
> http://lists.netthink.co.uk/listinfo/maypole
> 


=====
pjs

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com