[Maypole] The Future of Maypole

[Sebastian Riedel]

Max Maischein:
> >>>>Incidentally, as the youngest kid on the block, it might be a good idea
> >>>>for Maypole to check out what some of the more mature MVC frameworks for
> >>>>Perl have done about things like abstraction and declarative
> >>>>programming.
> >>>
> >>>[...] if you do this,
> >>>then you become very tempted to go mad and redesign your framework to steal
> >>>what you think are the cool features of everyone else's frameworks. Not
> >>>necessarily for any technical merit, either, just to keep up with the
> >>>neighbours.
> >>>
> Personally, I've looked at Maypole with much interest since its earliest 
> beginnings, and while I haven't been overwhelmed with quality in certain 
> locations, the overall quality of Maypole was really good, at least for 
> the use I see in Maypole - a quickly prototypeable frontend for a 
> database. The documentation quality has increased and with 2.0 it is 
> good, at least good enough for me.
> 
> What worries me is the Big Data Driven Approach currently taken, as the 
> configuration "language" (for example YAML) is now a fourth language 
> involved - there is only so much abstraction a toolkit can take, and I 
> don't need much abstraction in Maypole once I sold my soul to TT 
> (reluctant) and CDBI (willing).
> 
> > I'd love to see Maypole settle down. Maypole needs to be more defined. 
> Yes. I'd like to see the current (Maypole 1.7 / 2.0) Maypole to be 
> accepted in more places as a potent seed for web applications. But for 
> that to evolve, Maypole itself must mature, and it can't mature if the 
> whole infrastructure changes every 5 months - if I wanted that, I'd 
> program Java...

Absolutely right, thats why i took my Maypole3 ideas and moved them into
a subproject (Catalyst).

Catalyst now completely aims at enterprise applications, it covers most
features of a typical servlet container (api, sessions, contexts),
struts-chain (the next-generation struts using the chain of
responsibility pattern), ruby-on-rail (multiple controller support) and
adds some weird stuff like AOP features (thats a new idea).

It also completely separates the flow from the code (applications
designed to be modified/refactored), cool stuff, you'll see... =)

I'm very sure there are many features that'll get backported, like the
extensive debugging/profiling features, header/cookie handling, redirect
and http status support...

So you see, it doesn't directly compete to Maypole, it's just a
Maypole-like alternative, when Maypole's not enough for you... ;)

Btw. YAML is not the configuration language, it's just a plugin to
simplify configuration.
The configuration is still just a Maypole::Config/Catalyst::Config
object containing perl structures.
So you can just use raw Perl or write your own plugin to configure your
application, even xml. ;)

> 
> Maypole has many ugly warts that need some Best Practices to evolve, 
> like the best way of more flexible path management without involving 
> mod_rewrite and CGI parameters, and it needs to expand horizontally, for 
> example with a good, maintainable and low-overhead permission system, or 
> handling of images and basic user/login features. But all of this needs 
> a code base that does not change its outside interface.

IMHO there are also some design issues that need to be addressed, like
debugging/profiling and multiple view/model support...

sebastian