Re: Mason 2.0 thoughts

On Mon, 30 Apr 2007, Jonathan Swartz wrote:

> * I agree that it is more worthwhile to focus on the templing portions 
> of Mason for the future, and to encourage people to consider more modern 
> mvc frameworks for the controller aspects. That said, many sites will be 
> using Mason in the traditional way for a long time and this needs to be 
> fully supported.

I agree that people will be using it, but I personally don't have a lot of 
interest in this piece. I'm not likely to spend much time working on it 
after it's initial creation.

> * I'd reduce "Things to Break" to an absolute minimum. Users hate 
> gratuitous backwards incompatibilities, and we got justifiably slapped 
> for this when we broke things unnecessarily for version 1.1. If you're 
> going to break things, you have to at least compensate users for their 
> porting efforts with groundbreaking new features or architecture. We did 
> that for 1.1, but I don't see this happening again in Mason's future.
>
> For example, <%filter> is ugly and I wish it had been designed 
> differently, but is used in enough sites that we can never get rid of 
> it. object_file_extension was probably unnecessary, but what's the big 
> win in eliminating it and annoying the four users that are using it? :)

I guess my idea is that people will have Mason 1.x for a long time. Why 
bother with any big re-architecture of the codebase is we can't also make 
some real changes at the same time. The <%filter> problem is particularly 
egregious, as its been an endless source of bugs, and its behavior has 
never been all that well specified.

One possibility might be offer a backwards compatibility option that 
implements filters in terms of components with content or something.

But really, the main reason for removing some crufty old bits is to make 
the project compelling for the implementors. Personally, if I had to 
support every little bit of the existing API as part of this work, I would 
be less interested in doing it.

> * A more considerate way to do the split, IMO, is to keep the framework 
> in HTML::Mason and move the templating portion out to Template::Mason. 
> Even then, we might use some package name trickery to avoid breaking 
> current users who are depending on the HTML::Mason::* namespace, e.g. 
> HTML::Mason::Commands.

I think the Template namespace has been more or less claimed by TT, 
unfortunately. I wouldn't object to leaving the framework pieces under 
HTML::Mason, however.

> * The one advantage of $m->cache is that it automatically separates 
> caches into private namespaces based on component, whereas AFAICT, 
> Catalyst has everything writing into a global cache. It would be 
> unfortunate to lose this feature.

This would still be available in the framework side.

I don't see this being needed for the template piece, though. One thing 
I'm realizing when I use Catalyst is that I'm inclined to do more work in 
the controller before calling templates, and then I pass in more stuff to 
the view when it's called. Given this, I've been doing caching in the 
controller and controlling the namespace there. It _would_ be nice if 
Catalyst had an auto-namespaced cache, however.


-dave

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

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