On Fri, 19 Nov 2004 15:08:00 +0100, Marcus Ramberg wrote
> Simon Flack wrote:
>
> >On Fri, 19 Nov 2004 10:21:27 +0100, Sebastian Riedel wrote
> >
> >
> >>Funny, in Catalyst we have split the Maypole Request in Context,
> >>Request and Response.
> >>
> >>
> >That is very similar to what I have in mind for Maypole. But I don't think we
> >need that separation - one request object should be enough. I don't think we
> >need that complexity, but I think I understand why you need it for Catalyst.
> >Can you use custom context/request/response objects.
> >
> >
>
> Last week you were complaining that we were doing mean things to
> Maypole in the release of Maypole 2.0, this week you are proposing
> major architectural changes. Separating the request object from the
> "controller" (the application object, imo, Maypole's controller is
> actually fused into the model classes, not the request object) is a
> more major change than anything that was done for Maypole 2.0.
I still stand by my original statement of not wanting to make widespread,
sweeping changes to Maypole. I'm going to concentrate on documenation and unit
tests, and get a release out of the door without this change.
And I don't think it's as big a change as you think. I don't understand what
you're saying about the controller being fused into the model classes. Sure,
they're using the controller object, but only because it's also currently a
request object.
> I don't see the actual problem you are solving. I understand your
> concerns regarding the bloat, but this design together with multiple
> inheritance is what provides Maypole with it's easy and flexible
> plugin architecture. Cleaning up handler_guts seems like a more
> relevant change.
The multiple inheritance, coupled with Maypole::Application actually makes it
more difficult to test and maintain, IMO. I want to clean up handler_guts - I
think in general the controller needs a cleanup and a bit of a rethink, and
that includes separating the request from the controller. The way I see things
is this:
The controller (your application) processes a request. That's what
handler_guts is doing. But in actual fact, it's processing itself and passing
itself through the maypole object model. I think that's bad abstraction. I'm
not blaming anyone for that, but in the long run I believe it will lead to
tighter coupling between the model and controller unless we split off the
"request".
I only touched on some of the problems with the controller in my email. But
the changes I propose aren't as drastic as it seems. Maypole will still be
Maypole, it'll just be a bit shinier.
> With regards to making maypole easier to debug, using warn and $r-
> >debug isn't really the problem either, getting warnings into
> intelligent places, and warning people about common mistakes is the
> real problem. Introducing a new logging class does not help that.
I don't see your point. Adding warnings doesn't help either. Documentation
will help people avoid common mistakes. And also better error handling and
error recovery. But that is separate from debugging.
Maypole won't require a logging class. There will be trace messages in
"intelligent places", that can be warn()d with a logging class if you so desire.
> I'd still like to see a maintainer who's dedicated to improving
> rather than changing Maypole. After a week with you not even
> contacting me to get write access in the repository, and proposing
> to do major API changes, you don't seem to have that focus. Maybe
> you would be better off working with Sebastian on Catalyst?
I've not contacted you wrt write access, because I've not needed it. Read
access has been sufficient. I already said that I wanted to draw up a TODO first.
I hope I've made it clear that I don't want to change Maypole. Not radically
anyway. I'm not proposing any new features, or a vastly different API. I've
just expressed some ideas for cleaning up the controller.
> Personally I'm trying to finish some Maypole applications in the
> current framework at the moment, I think this would be a good path
> to realizing what kind of improvements Maypole really needs, and I
> also feel it would be very good for Maypole itself to get some
> finished open source applications as a showcase.
Yes, that would be great. No arguments there :)
--simonflk
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT