Re: extending <% | %>

On Thu, Feb 14, 2008 at 01:41:30PM +0100, Scott Lanning wrote:
> Would backslashing non-delimiting pipes be bad?
> 
> <% $x =~ m(foo\|bar(baz)?)  %>

Well, it breaks backcompat, which is one of the things I was hoping to avoid.

> Like I was thinking how you could pipe SQL to a database

I admit that this is a pretty interesting idea, but probably not what we want
to encourage people to do in their templates. :)

> Note for example that something like
> 
> <% $object->expensive_method(\%args) | cache(expires_in => "10m") %>
> 
> could also be done from a <%perl> block, leaving
> 
> <% $cached_val %>
> 
> within the non-code part of the template.

Of course it could.  Responding to a sugar proposal by saying "you could do
this without the sugar" misses the point, though.

First, there's the fact that it's currently very inconvenient to do the "get
from cache or set", because it's not abstracted away in a generic way.  That
doesn't require new syntax, though; something like this could wrap it all up:

  $m->cached_or_do(
    sub { $obj->calc_some_stuff(@args) },
    expires_in => "10m",
    cache_key => "your face",
    # ... other cache options ...
  );

Once we have that, the real difference is between these two:

-----

<%perl>
my $cached_val = $m->cached_or_do(
  sub { $obj->calc_some_stuff(@args) },
  expires_in => "10m",
  cache_key => "your face",
);
</%perl>

# ... somewhere else ...
<% $cached_val |h %>

-----

<% $obj->calc_some_stuff(@args) 
  | cache(expires_in => "10m", cache_key => "your face")
  | h %>

-----

I prefer the second:
* the code you care about is at the top
* 'modifiers' (cache, h) are clearly separated
* maintained in one place in the code, not two

I keep coming back to 'cache' because I think it's the biggest potential win.
Fine-grained caching like this is something that I'm not aware of in any other
Perl template module; for example, Template::Plugin::Cache works at the
template level, not at the individual [% statement %] level.

Caching for even a short period of time can have a huge effect on application
responsiveness, so we should make it as easy as possible for people to cache
output.  HTML and URI escaping got special sugar because people need to use
them all the time.  If caching is far behind, I think it's because it's
frequently too much hassle, not because it wouldn't be useful.

hdp.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/