--- David Baird <dave at 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 at 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
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT