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
_______________________________________________
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:56 GMT