perrin,

Yeah I saw those already and have followed the chain of emails on the list. I must say that I have had some of the same experience as you with the very limited documentation so far, but that I seem to still be enamored by the toolkit. I find it feels very natural to my style of coding web apps. I hope that you would put some effort into expanding the documentation where you had found it to be very light as you update your slides for OSCON. I plan to where I can as well.


-Waswas

Is there another version of the the slideshow out there other than a .sxi file? Crap, what is a .sxi file anyways?

http://rawmode.org/~gabbana/mvc_slides.pdf

It's Open Office. I tried to export it to PDF, but it mangled the graphics. Maybe I can find a better PDF converter somewhere.

• First it's elegant ! it's a MVC Framework which fullfill all my needs in a simple way, while being easy to modify.
• The helpers allow you to unleash your lazyness, producing a lot of code (I hardly can call it a skeleton, as it's rather a complete application in the case of Catalyst::Helper::Controller::Scaffold)
• The included HTTP::Server is a big win for rapid prototyping/test (But using Catalyst on 'real' Web Server like Apache isn't a problem and is even the common practice)
• You're not tied to any technology for model or view components
• The Perl automated tests framework is used and promoted.
• And best of all the community is very responsive and answer all your questions on the #catalyst channel.

sri,

I have been lurking for a while on the mailing list archives, it looks pretty active. I really like everything that you guys have done so far. I just wanted to get more of a feel for how much people here had been using it in the wild -- I have gotten bit on some newer frameworks that seem to have a good start but peter out over the next few months.


-Waswas

Hi,

Have done some CRUD with Maypole, but performance is not amazing, and read the documentation about Catalyst, and had the same question, about how long it would be actual, maintained, how devel, etc... So it's nice to see that there're more people on the same position that I'm. And of course, great to see comments from the authors!

I was thinking about using Catalyst for the refactoring of a complex internal webapp. It'll be a long timing task, it's Perl+C, but the person who wrote it, was learning Perl on the way, strange style and don't use the nifty things you would expect...

Regards,

From what I have seen so far, Catalyst seems to serve up pages very quickly vs Maypole (in my converted apps about a 6 or 7 fold speedup). Good to know I was not alone in my worries...


-Waswas

We've spent a huge amount of time optimizing the dispatcher, so it should be much faster (and especially more versatile) than Maypole and Ruby-on-Rails.

Voila!
http://home.ngmedia.net/chansen/catalyst/ppms/

Don't know for PPM but for those using Debian looking for .deb just add in your /etc/apt/sources.list :



#catalyst
deb http://pkg-catalyst.alioth.debian.org/ binary/
[download]


"Only Bad Coders Code Badly In Perl" (OBC2BIP)

This mostly depends on how much you forward in your app.
There is no standard, but nobody ever complained about this, so it's definately no issue. ;)

I do have some questions for you, however. Why to you lump CGI::App into those that you feel "are geared towards CRUD"? The reason I ask is that CRUD is not typically what I develop with CGI::App. The stuff I develop with CGI::App varies widely, but is typically of the landing page-search results-view individual variety, or data capture (vs full-blown CRUD).

(A cursory glance at Catalyst indicates that it shares one important thing in common with CGI::App: a page is a method (cgiapp uses the terminology run mode). With this paradigm, your class indicates what the available run modes are, what to use if none is passed or an invalid one is specified, and you go from there.)

Additionally, you indicate that "anything more complex [than CRUD] seems to start fighting the API". Could you explain what your experience is, and why you find this to be so? I've developed many complex applications with cgiapp, and your statement doesn't seem self-evident at all. I'm curious if it really applies to the other frameworks you list as well.

From the buzz I've heard and my cursory glance through its docs, Catalyst sounds quite well-designed. However, the other frameworks you mention have been around for quite some time and have active developer communities; I'm curious to know what sorts of applications you have in mind that they would not be able to address. I'm wondering if it's more a matter of Catalyst more closely matching your personal coding style than the inability of the other frameworks.

Sorry I did not mean to group CGI::App with the CRUD comment. My problems with CGI::App are that I tend to feel like I need to recreate the wheel every CGI::App app I create. It seems to be so lightweight that you have to build up a ton of the inner workings that make sense for the web framework to provide. After I am done -- I am left feeling as though I spent half my time writing code to make the framework, you know, work. I get the icky feeling every-time I build around CGI::App that I could have done the same thing quickly just building a quick dispatcher on my own. Catalyst seems to add much more groundwork, but at the same time I can overload and change its core behavior pretty quickly without much hassle.


-Waswas

Your comments seem very much in line with Perrin's analysis in his slide presentation: CGI::App is suited for those who want high flexibility so they have control over their site. The syntax and methods are both flexible and extremely simple -- making it both easy to KISS, as well as to overdevelop ;-)

My personal experience is that I develop a framework for each site I work on, and wrap utility methods/common functionality into a CGI::App superclass. The application framework -- cgiapp -- lets me choose what needs to be present, and what doesn't need to be. Every site is a little different, and I don't like to have more functionality in the application than is necessary.

As an example, I might want a class that simply loads template content into a sitewide template. I have one run mode, and setup a default page if none is passed. Done.

Another site might consist of several applications. The body content needs to go into the sitewide template, and I need breadcrumbs to the application. These items go into the superclass, and the individual application classes provide hinting so the superclass can do its job at the end.

I appreciate larger frameworks -- they're great for prototyping more complex applications -- but in the end I've found that a lighter-weight framework like CGI::App suits my personal needs as a developer, because it allows me to build frameworks tailored for the sites I'm developing.

It sounds like Catalyst more closely suits *your* needs, however, and that's what you need to think about. If you're worried about the longevity of the project, you can always step up as a developer... ;-)