[Maypole] (no subject)

Marcus Ramberg marcus@thefeed.no
Fri, 19 Nov 2004 15:08:00 +0100


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

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'm happy to hear 
that you want more tests. So do I. That's why I changed Maypole::CLI to 
make it easier to write template tests and test the view in version 2.0.

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?

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.

Marcus