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

Sebastian Willert willert at gmail.com
Wed Sep 19 00:39:13 GMT 2007


On Tue, 2007-09-18 at 16:59 -0500, Dave Rolsky wrote:
> On Tue, 18 Sep 2007, Sebastian Willert wrote:
> 
> > In my opinion there is a large need to keep Catalyst::View::Mason
> > backwards-compatible and I think it is important to stick as closely to
> > the constraints set by Catalyst::View::Templated if you are to build a
> > view that is based on it. I guess these two requirements are mutually
> > exclusive or at least would introduce large amounts of backcompat code
> > into Catalyst::View::Mason that would be really hard to maintain. I also
> 
> If C::V::Mason really can't change, and this really is the way forward, 
> then at least C::V::Mason should be marked as deprecated. But have you 
> talked to Florian Ragwitz, the current maintainer of C::V::Mason?

I haven't yet, because as said before this module has some
insurmountable differences, but see below for further discussion on
that.

I am more than willing to help porting the changes that are compatible
back to C::V::Mason, though. I had assumed that these changes would
trickle down anyway, but I first wanted to get the release of
the ::Templated version out of the way first.

> > 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.

> 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.

> > As for writing a patch for Mason itself: I think having named roots is
> > desirable and well supported within Mason. Mason is also unlikely to
> > have an external entity to rely on the INCLUDE_PATH to be presented as a
> > plain array. This does not hold true for Catalyst so I tried to find a
> > sensible way to unify them and took great care to build sensible root
> > names from unnamed paths. But maybe it would also be a good idea to
> > provide a comp_root configuration variable and map the paths given there
> > back to INCLUDE_PATH as a second option.
> 
> See above for the whole compatibility thing. I think it's a bit of a red 
> herring here. Different view implementations (aka templating systems) are 
> generally wildly incompatible anyway, so making the Catalyst view for each 
> system look different is no big loss.

Templating systems are wildly incompatible. RDBMs even more so,  and we
still have DBI, DBIx::Class and assorted ORMs that try to abstract away
these differences. If you look at the views themselves I don't see any
large benefit either, but having a mostly standardized view API will
enable much higher feasibility of view agnostic catalyst components.
INCLUDE_PATH might indeed a red herring here, but I tried to respect the
decision to include it in the common view API and I was able to
accommodate it with much of code but with few trade-offs so I was happy
with this solution.


> > To wrap thinks up: I really think Catalyst::View::Templated takes an
> > desirable approach in trying to unify view configuration and APIs, even
> > if there are lots of hops to jump through to map between the Mason way
> > and the C::V::T way. I tried to allow the Mason variant wherever
> > possible but discouraged it in the documentation because sticking to the
> > Mason API is contrary to the main motivation behind
> > Catalyst::View::Templated.
> 
> I'm not sure _what_ the motivation behind C::V::Templated is. Jonathan's 
> now saying it's wrong approach!
> 
> What I do think is worthwhile is unifying _output_ handling, for example 
> making sure the charset is always set in the content type. Unifying 
> configuration seems pointless to me.

INCLUDE_PATH might actually prove useful down the road. I've migrated
few projects from TT to Mason myself, and this process would have been
much less painful with a Mason view that would be able to fall back to
TT rendering if it can't compile the template on its own. Such a view is
trivial to implement if the include path is standardized. Such a view
would be unsuitable for production code, maybe this idea is even
braindead, but it might serve as an example what might be possible due
to standardized configuration.

Jonathan's decision that C::V::T is the wrong approach comes a few days
to late for my module, unfortunately. I totally agree that output
handling and charset issues are the most important issue to deal with
but I don't think that you loose much by supporting things like
INCLUDE_PATH if you make sure that there is an easy upgrade path for
users of views that don't conform to the C::V::T interface. 

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.

The undeniable drawback is that some views would have to release a
separate ::Templated version, but Mason is done and TT should get away
with supporting C::V::T without incompatible modifications given that
C::V::T is modeled after TT, so we have the two big ones covered.

Cheers,
  Sebastian




More information about the Catalyst-dev mailing list