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

[Dave Rolsky]

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?

> 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

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!

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

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


-dave

/*===================================================
VegGuide.Org                        www.BookIRead.com
Your guide to all that's veg.       My book blog
===================================================*/