web-dev and perl (mason, catalyst, embperl)

[halfcountplus]

Which that is a somewhat wishy-washy title, I am fishy-fishying for opinions ;)

I've only been programming for a few years; I actually got interested via perl on linux and for the past year have been mostly studying C, but still have an attachment to my first love :)

Motivated by a need to maintain small websites for some C projects I've gotten involved with, I've also been picking up javascript/DOM/AJAX. A while ago I wrote myself some little CGI and DB modules to help with CGI scripts that spit out javascript and (surprise!) deal with databases in a dynamic way. That led me to an awareness of "web application frameworks" and about a month ago I started with ruby & ruby on rails.

Via RonR I've learned the MVC model and about dealing with SQL (my 'lil perl CGI/DB modules just use Storable). Which is great, it all seems very clever to me, etc, etc. At this point, tho, I have decided to step back from ruby (which is nice) & RonR and assess my original motive, which was largely a desire to use HTML embedded perl the way I see PHP used. At that point (way back in April!), I was under the (probably misguided) impression that embedding perl in web pages was freakish and unusual, and that if I didn't want to go with PHP or ASP then RonR would be a more realistic option.

It is beginning to dawn on me that that is not really the case, so as part of my "stepping back and assessing" process I've decided to give Mason a whirl. I am still flabbergasted by the evident proliferation and "high-profile" of ruby on rails in contrast to the evidently near clandestine mason/catalyst/mod_perl realm. Or am I wrong?

SO, basically, the purpose of this post is to casually pick some brains of those who have some greater knowledge and experience of MVC style web programming with perl. I explicitly mention MVC because I do like the concept, however, a lot of the "web programming" I see myself doing is not really database centric, it simply may involve a database. Ruby on Rails is very strictly tied to MVC, and I do not think will lend itself itself well to small sites that may not require any DB at all, but could still benefit from the "embedded script" dynamic. Really, I would be happy to just write CGI type scripts that deal with html embedded perl, but recognize CGI itself is not *quite* sufficient for that. I don't at all mind having to do more coding in order to pay for something more flexible than RonR (if my point is clear here). Anyway, Mason, catalyst, embperl users, please commence opinionating!

[romkey]

I was working with HTML::Mason before I started using Catalyst - it was comments from one of the Mason developers about Catalyst that lead me to it.

Most Catalyst users seem to stick with Template::Toolkit, but I prefer just embedding Perl in HTML, and Mason is great for that. You'll be able to use most Mason features in Catalyst, but ignore dhandlers; Catalyst takes over their role. Make sure that you use Catalyst:View::Mason and not Catalyst::View::MiniMason (that may not be the correct name), which loses many of Mason's most powerful features (like autohandlers).

You'll most likely want to use DBIx::Class::Schema to handle your Catalyst models. Catalyst is model-agnostic; you can implement your models however you want - but DBIx::Class::Schema is very well supported out of the box, with Authentication and Session plugins ready to work with it.

Many Catalyst users end up using fcgi instead of mod_perl. It's minimally slower and provides more flexibility - it's easier to make multiple sites work under one server, and you can restart a site by restarting the fcgi processes rather than restarting Apache.

One of the key things a lot of people working with Catalyst (and I assume RoR as well, because it's not really a Catalyst issue) have problems with is where the logic of the application goes. I've been guilty of this myself. Try to think of the model not as just a database but as an API to the application itself, so that you could (if you wanted) provide a command-line interface to the application by wrapping appropriate code around the model and not using Catalyst at all.

A benefit of that approach is that it's easier to write unit tests for the model. It also tends to lead to less duplication of code, and is generally much cleaner.

I've been very happy working with Catalyst. It's actively maintained and evolving and has a small but very helpful community of users online. The mailing list and IRC channel are great resources.

The biggest warning I have about it is to be careful with the online documentation. Google will often turn up old versions of online docs, and it's easy to accidentally be coding against documentation for a module which is several generations old because Google didn't get you the current generation. I've had this happen to me, and I've seen it happen with people on the mailing list too. The community puts a lot of effort into keeping the documentation up to date, but can't control what Google returns.

[Your Mother]

romkey's discussion is good.

which was largely a desire to use HTML embedded perl the way I see PHP used

Mason will do this for you. I don't recommend it (the PHP-like approach, not Mason). It's much easier for the developer up front and at first. It begins to cost you later and tends to make code that you and you alone can happily work with exactly once. If you come back to it a year later, it will be mysterious and frustrating because so much of it can be arbitrary and tied to your specific understanding at that time of how to solve a problem. Other devs or designers might not be able to work with it at all.

When I'm doing simple/one-off stuff I just use CGI.pm. Otherwise Catalyst is great. CGI::Application would be my next choice because it's clean and approximates the way I (used to) write CGIs.

Embperl is apparently stable but seems more or less abandoned. I worked with it... 8 years ago? Haven't seen it since, though some folks still seem to like it.

Catalyst is difficult to start (learning curve). It pays you back later when adding features, refactoring, or fixing bugs. All the things that don't seem important when starting but kill you and your time down the road.

[webfiend]

It's purely a personal style thing, but I tend to pull out CGI::Application even for my simple/one-off stuff. Why? Well, my one-off stuff almost always evolves into (2 .. $n)-off. Eventually my planning patterns just evolved into a make-way-for-change approach.

Mostly I'm still haunted by the memory of a script that I'd planned as one-off but kept using for years. I still see that ugly code staring at me in the middle of the night.

You might not have the myriad assortment of issues that I do, though.

[Your Mother]

You are wise. I usually "inline" my Template/Alloy template in the __DATA__ (with blocks representing different wrappers/fragments) of a one-off so it ends up being both fast to write and easy to break out if I have to later. I like CGI::Application and I think it's one of the right ways to do it; for me personally it falls between too little (doesn't cover what Catalyst does) and too much (I can write dispatch table and such for a straightforward CGI in a few minutes).

[perrin]

I'm not sure exactly what you're asking, but in-line perl in the form of Mason and other tools is widely used, and used on much larger sites than Rails. If you want a simple option for MVC development, CGI::Application is quick to set up and runs well on plain CGI servers as well as mod_perl and FastCGI. You can use any of the popular templating systems with it.

[jdrago_999]

There's Apache2::ASP but it requires mod_perl, which generally means you are paying for a dedicated server (and installing everything yourself).

[halfcountplus]

(First thanx all for your informative replies. Mason seems very nice, I feel a weight has been lifted from my shoulders.)

I was just looking into this mod_perl issue. I notice that there is a way to use Mason with just a cgi handler, but this requires adding some configuration to apache, which I assume will not be allowed at (eg) sourceforge. Still not a too big a deal I guess...plain 'ol CGI + AJAX can do a lot. When I really have something that deserves more, I will just have to dish out $20/month for a slice somewhere.