Stop re-inventing the wheel. Reusable frameworks?

Our development shop often takes on new projects for in-house use, or for third parties, and the same problem always pops up - we re-invent the wheel.

We're an application service provider, so most of our projects involve a backend, frontend, maintenance scripts/crons, etc. We glue together our framework which is usually a DBMS (like Oracle, Sybase or MySQL) and several packages/units in Perl, Python and C++.

There is some code re-use for the more complex issues, but for the more basic user-experience framework, we still re-invent. We've been looking into Java, tooled around with Zope, played with PHP, and even in the Perl realm (where I'm most comfortable) looked at application frameworks like CGI::Application.

My question to any you web application developers is, what is your framework, and is it re-usable? Are you strict MVC (model view controller) dev-houses? I was speaking with a fellow who runs a fairly decent size development house out of the U.S. and India (handful of developers here in the states, and 60 back in India), he said over the years, they've built their own set of tools so that they no longer re-invent the wheel - so they truly do accomplish rapid application development. That's where we'd like to be and I just wanted to know about the tools of your trade.

mod_perl, HTML::Template, CGI::Application, DBI, DBIx::FullTextSearch, and related modules are my framework.

Interestingly enough, the CGI::Application folks have recently released modules aimed at making setting up a CGI::Application easier, with an eye toward standardization.

http://theoryx5.uwinnipeg.ca/CPAN/d.../Generator.html

I REALLY like this set of modules- they offer all the flexibility, speed of development, maintainability and speed of execution I could possibly need.

Of all the templatting systems I've seen, HTML::Template I think makes the cleanest separation, which also facilitates making HUGE changes to your application without ever touching perl. It's very cool.

Anyway, I wish I worked with multiple perl developers on my projects- I'm the only perl person in my project. I believe that the above framework would scale VERY well for multiple developers, because of the good OOP practices it encourages.

I'm a broken record. I've been using this framework for the last 2+ years and I can't get enough of it.

I'm on the CGI::Application mailing list and I've noticed quite a few new additions to that module branch. Here's a question: where do you put your session authentication in a CGI::Application based framework? cgiapp_init?

In the mailing list they were discussing, for a while, best practices documentation -- and indeed, I was hoping for the same thing.. before I start going a more inefficient development route.

The Perl pieces we glue together are mod_perl, HTML::FillInForm (love this one, but found one short coming in dealing with drop-down lists), DBI, CGI::Minimal, and a handful of other ones.

Sessioning for me is spawned in cgiapp_init by CGI::Session::MySQL, which is an excellent module, by the way. Easier to use than Apache::Session and it gives you everything you need in a sessioning system.

Going CGI::Application/HTML::Template is most definitely going to be better than a homegrown system, a lot of thought has gone into the architecture and it's used by quite a bit of clever perl hackers.

Hero Zzyzzx - sounds interesting. You know what really looks interesting is CGI::Application::Generator. Sounds like a really nice way to translate our planning framework diagrams into empty module bodies. I'll be sure to look at CGI::Session::MySQL. Our own session modules we've re-invented 20 times over are neat, but I'm always for looking into new things.

We started using RT (request tracker) a while back and one thing that I really liked was their access level schema. Check it out (very wide image, all the way to the right) -- it's their entire database schema beind this really nice e-mail customer service ticket-based system, and more specifically, the ACL is simple and extensible. Explanation is at the very bottom. Anyhow, this is something that I'm starting to model for our in-house use when building out new apps. It was truly love at first sight.