Peter Speltz wrote:
> --- 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 just seems a little odd to me to alter the relationship between the
model and the view by setting a template variable. It feels more like a
hack than a proper solution. I don't mean any offence, we may have to go
with hacks for the short-term to preserve compatability, but I'd like to
know what the ideal solution would be first.
> 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;
>
> .. .
> }
That syntax looks quirky to me. I'd rather change Maypole::View::Base to
set each param individually than to add to the list of parameters that
we need to support.
> 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.
I'm not sure we need the extra complexity. Everything in 'classmetadata'
is already the result of a method call on $class.
We could just *always* provide classmetadata.name and make the rest of
it optional. Then you can call the methods you're interested in from
your template (e.g. with Template::Plugin::Class). And from the sound of
it, you can do the same in Mason without a plugin.
--simonflk
_______________________________________________
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