WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
On Fri, Apr 13, 2012 at 06:48:34AM -0400, Nic Zero wrote:
> I too have recently rewritten CGI::App and most of its core plugins.
> That was not my original plan.?? You may remember recently I was
> recommending people make use of class-level initialisation and
> only do object-level initialisation (ie per cgiapp instance) for those
> things that can't be shared.?? However, when I looked into it more
> deeply (as part of a separate task) I found that support for this
> within plugins is quite sketchy and unreliable.?? CGI::App itself
> doesn't really support the idea in any clear way.?? I also thought
> that rearranging the code inside CGI::App would help me and
> others understand the flow better.?? So I started to refactor.?? But
> then I encountered code that is convoluted, for example a six-
> line subroutine that was much clearer in one line.?? So I started
> to rewrite.?? And then I decided the whole thing would be easier to
> code against as well as easier to read if I made my Stash plugin
> be used within CGI::App itself (much like Catalyst & Mojolicious).
> So then I realised I was departing from being CGI::App
> That's where that story ends.?? As soon as you've broken
> compatibility you've distanced yourself from the CGI::App
> community and your one-man project is dead.?? My time wasn't
> wasted cos I then refactored again so that the good bits are
> separate extensions that can be used with CGI::App or
> Mojolicious.?? [They're close to being published; tests need to
> be improved and documentation needs to catch up.]
..ah, yes..the community - that's the compelling part about CAP for
me. I like this list a lot, for example.
> I thought that my micro-framework would still fill a niche: those
> cases where you want the functionality of Catalyst but with a
> 1 MB du footprint.?? Unfortunately those smart people over at
> Mojolicious had a fabulous 2011 and can do much more than
> my framework and still sit inside 1 MB.
> So if you're still reading, my strong recommendations are:
> * Respect CGI::App for what it is.?? If you need more, go see
> Mojolicious::Lite and Mojolicious itself.
> * Ignore people like Ron & me who are tempted to do rewrites
> that will never have the community that CGI::App grew.?? Two
> years from now both of our frameworks will still contain more
> bugs and fewer working examples than CGI::App.
I am less inclined to use something other than CAP proper, but
Mojolicious looks interesting. Something about how much it hides is a
little unerving to me, though.
I have routes set up fine using CAP::Dispatch (which also supports the
HTTP methods for the clean URIs. Beyond setting up the routes, I am
not sure what Mojo gives me since I still have to implement my backend
to push and pull data. It is a lot cleaner looking, but one thing that
stands out to me are those templates in Mojo - out of the box, they
seem way to powerful (I am a fan of super dumb templates).
> * Ron, if you do continue with Snapp, try borrowing some of
> the smart ideas from Mojolicious::Lite, but
> * like me, I suspect you'll fall in love with Mojolicious and
> Snapp will just be an amusing memory.
Thanks, everyone. And thanks, Ron, for your efforts - I don't think
any effort to improve things or to learn is time wasted. Most OSS
projects out there are "one man" or "one off". I have a few myself =).