[Catalyst-dev] RFC: Catalyst::View::Mason::Templated

Jonathan Rockway jon at jrock.us
Thu Sep 20 19:28:18 GMT 2007


On Wed, 2007-09-19 at 01:39 +0200, Sebastian Willert wrote:
> On Tue, 2007-09-18 at 16:59 -0500, Dave Rolsky wrote:
> 
> > > Because uppercase is the default case for C::V::Templated. I find it
> > 
> > I'm guessing it's the default because the author was making it look like 
> > TT. It just seems weird if you're familiar with Mason's config parameters
> 
> Most likely this is the case, yes.

Yup :)

> 
> > More to the point, what does it matter if it looks like other views? It's 
> > not like you're going to swap out views and try to keep the same config!
> 
> But it is quite likely that some module might take advantage of the
> publicized interface of a common superclass. Maybe its because I have a
> strong background in Eiffel, but I believe in design by contract and POD
> is the closest thing we have to an API contract. Violating a contract
> needs very strong reasons in my opinion and I can't see any here, apart
> from habituation.

I agree with you here.  I don't see why the interfaces to different
template engines should be different.  The things that are the same
should work the same.  Most people want to say "render foo", and the
template engine translates that to "render
$TEMPLATE_ROOT/foo.$TEMPLATE_EXTENSION".  I don't see why we shouldn't
try to keep the APIs the same.

What I did in the other Views I converted to Templated was to accept
both the Templated ALL_CAPS config, and accept whatever the older
version did also.  This way everything works the same for both Catalyst
users (expecting a common API) and $OLD_VIEW users (expecting the API
that they know and love). 

> 
> Jonathan's decision that C::V::T is the wrong approach comes a few days
> to late for my module, unfortunately.

My apologies for this.  Thanks for the time you've spent so far trying
out the API.  Eventually we will get this all figured out :

> 
> I have to admit that I feel a little bit stupid, just after I hopped on
> the C::V::T bandwagon Jonathan declared that it was a bad idea to begin
> with, but I am not quite convinced. The one annoying thing with
> supporting C::V::T with a Mason view was the way Mason handles its
> comp_root and I guess having ordered _and_ keyed include paths is quite
> unique in this realm.

This is not your fault.  I am the stupid one. :)

Here's what I'm thinking.  I want to keep an API around such that
a ::Templated subclass only has to implement C<_render> and
C<new>.  ::Templated will ensure that $view->template is what the user
wants to render, and that $c->process and $c->render work properly.
These are problems that View authors have had, and these are the
problems that ::Templated solves correctly.

The question remaining is whether or not to keep the unified
configuration.  I think we could all be happy by accepting new-style and
old-style configs for the views.  The individual author can choose which
to document.  But, that's a lot of extra work... so I'm open to
suggestions.

We would be able to move the current Mason and TT views to be subclasses
of Templated if we forget about the whole config problem, right?

Regards,
Jonathan Rockway




More information about the Catalyst-dev mailing list