Re: Mason 2.0 thoughts

>>
>> Maybe a new block type and some flags.
>>
>> <%cache key="0xdeadbeef" expires_in="5 min">
>> [content]
>> </%cache>
>>
>> I think that using flags for (basically) arbitrary data would end  
>> up being a
>> huge nightmare, though, unlike the <%args validate=PV> example  
>> given on the
>> wiki.
>>
>> Is there a reason that something like this wouldn't work?
>> % cache {
>> [content]
>> % } (key => "0xdeadbeef", expires_in => '5 min');
>>
>>   sub HTML::Mason::Commands::cache (&@) {
>>     my ($code, %arg) = @_;
>>     # do some stuff with either $code->() or looking at the cache
>>     $m->out($result);
>>   }
>>
>>
>
> I don't get why people think we'd need something new. This can be done
> as-is with the current Mason using the component-with-content feature.
> That's what I was suggesting in my original message.

Sadly, I think components are the wrong place to put this kind of  
functionality.

I've never liked or used CWC very much, and I believe one of the  
reasons is the same reason that Dave started putting form handling in  
subroutines (first with MasonX::WebApp, then with Catalyst). Many  
potential blocks/tags/filters - i.e. higher order functions that take  
a piece of Mason template as an argument and process it in some way -  
will be all or mostly pure-Perl, and thus cleaner to write with a  
subroutine or method than with a component.

Take for example a "cache" filter, or a "strip whitespace" filter, or  
a "make all lowercase" filter, or a "fill in this form" filter. All  
of these are going to be 100% Perl. Why on earth would we put them in  
components, except for the fact that the CWC syntax is already  
available. They belong in modules. Beyond being cleaner, it allows  
people to contribute new collections of filters on CPAN, as with  
Template Toolkit. e.g. MasonX::Filter::FillInForm. [1]

Unfortunately, the two ways to do this out of the box are non-optimal:

     1)
     % cache {
     ...
     [content]
     ...
     % } (key => 'foo', expire_in => '10 min');

     2)
     % cache(expire_in => '10sec', sub {
     ...
     % }

The first is really unfortunate because the arguments appear at the  
end of what could be a very long content block.

The second is a little better, but the 'sub' annoys me, and gives me  
Ruby envy. :)

And both of these also suffer from being line based, and thus ill- 
suited to handle small pieces of content, unlike CWC and Rails blocks  
and TT filters.

So IMO it would be great to have a special syntax for these filters  
(or to co-opt an existing syntax like <% %>), a syntax that was  
nestable, and not line-based, and able to handle arbitrary Perl  
arguments.

Given that, it is somewhat unfortunate IMO that we came up with CWC  
first, because such a new syntax would be blamed for cluttering the  
Mason language unnecessarily, whereas in retrospect I'd rather have a  
module-based filter syntax than CWC.

Jon

[1] The TT equivalent: http://cpan.uwinnipeg.ca/htdocs/Template- 
Plugin-FillInForm/Template/Plugin/FillInForm.html


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/