[Mason-devel] subclassing requests & mason 2.0

[Hans Dieter Pearcey]

[intentional list change]

The code may be from the docs, but it seems a little suspect to me. For
example, one could have H::M::ApacheHandler loaded even if one was using
H::M::CGIHandler.

I agree. I think Dave has mentioned that the alter_superclass thing makes him
sad (he probably didn't phrase it quite that way).

Also, CGIHandler and H::M::Request::CGI have always seemed like second-class
citizens in the mason world to me; it's clear that things evolved first to
handle Apache/mod_perl and then sort of slowly to also cover CGI.

Abstraction of the input method might be a useful design goal for 2.0. It's
something that Catalyst has done very well, as far as my experience goes.

hdp.

[Dave Rolsky]

Post by Hans Dieter Pearcey
Abstraction of the input method might be a useful design goal for 2.0. It's
something that Catalyst has done very well, as far as my experience goes.

Which is yet another reason my main interest in Mason 2.0 is producing a
template system that works well with Catalyst, Jifty, etc.


-dave

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

[Hans Dieter Pearcey]

Post by Dave Rolsky
Which is yet another reason my main interest in Mason 2.0 is producing a
template system that works well with Catalyst, Jifty, etc.

I feel the same way.

We've talked a lot about new ideas and features for the Template side of
things, and I can't really think of much for Framework. Are there any major
changes you had in mind for it, or is it mostly refactoring, polishing, etc.?

hdp.

[Dave Rolsky]

Post by Hans Dieter Pearcey
We've talked a lot about new ideas and features for the Template side of
things, and I can't really think of much for Framework. Are there any major
changes you had in mind for it, or is it mostly refactoring, polishing, etc.?

Personally, I have zero interest in working on the Framework side at all.
I think the framework side already works well enough for people using it
(like me). Adding features to it seems pointless, since that time is
better spent on Catalyst or another more powerful and generic framework.

I'd like to see it go into maintenance mode, meaning bug fixes only. Of
course, if someone else wants to actively work on it, I'd be happy to let
them do so.



-dave

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

[John Siracusa]

Post by Dave Rolsky

Post by Hans Dieter Pearcey
Abstraction of the input method might be a useful design goal for 2.0. It's
something that Catalyst has done very well, as far as my experience goes.

Which is yet another reason my main interest in Mason 2.0 is producing a
template system that works well with Catalyst, Jifty, etc.

On the "etc." front, please make sure that the template input and output
mechanism are suitably generic. A callback for "give me the next piece of
this template" and another for "here's the next piece of output that I've
produced from that template" should cover all bases. On top of that can be
built the traditional "a template is a file on disk" and "output is printed
to filehandle foo" hook-ups.

-John

[Dave Rolsky]

Post by John Siracusa
On the "etc." front, please make sure that the template input and output
mechanism are suitably generic. A callback for "give me the next piece of
this template" and another for "here's the next piece of output that I've
produced from that template" should cover all bases. On top of that can be
built the traditional "a template is a file on disk" and "output is printed
to filehandle foo" hook-ups.

I expect we'll have something like the current Resolver class.


-dave

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

[John Siracusa]

Post by Dave Rolsky

Post by John Siracusa
On the "etc." front, please make sure that the template input and output
mechanism are suitably generic. A callback for "give me the next piece of
this template" and another for "here's the next piece of output that I've
produced from that template" should cover all bases. On top of that can be
built the traditional "a template is a file on disk" and "output is printed
to filehandle foo" hook-ups.

I expect we'll have something like the current Resolver class.

Does the resolver handle the template i/o too? I thought it just translated
requested paths to actual paths (and somewhat painfully, at that). I'm
thinking more along the lines of what the lowest-level Mason 2 template
engine would deal with, and it shouldn't be files or paths, IMO.

-John

[Dave Rolsky]

Post by John Siracusa

Post by Dave Rolsky
I expect we'll have something like the current Resolver class.

Does the resolver handle the template i/o too? I thought it just translated
requested paths to actual paths (and somewhat painfully, at that). I'm
thinking more along the lines of what the lowest-level Mason 2 template
engine would deal with, and it shouldn't be files or paths, IMO.

Right now the "get the source of a component" bit is handled by the
ComponentSource class. The Resolver and ComponentSource are pretty tightly
bound, and I have always sort of wanted to combine them, so I imagine in
Mason 2.0 there might be a single object responsible for finding
components and providing source and metadata (last mod time, path, etc).


-dave

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