I wanted to force as little upon a designer as possible. When a client says to me "Why should I install Apache over my current server? And why do I need to install an XML parser for this site?" I can immediately discount Apache::PageKit (and Apache::* in general. Yes, some clients are that pushy and do get their way like this...).

I can understand the comparisons to CGI::Application, especially when both modules have seemingly similar setup and execution methods, but ours allows programmers to explicitly compartmentalize the assorted parts of displaying a page (more on this below.), and allows the programmer an easy way to clone and modify pages. I will admit that I have only cursory experience with CGI::Application, though.

Moving on, CGI::Application also enforces the use of HTML::Template files. I personally do not care for HTML::Template. So, I wanted to code something more flexible...
I believe this will be the only module in its class to embrace and encourage the usage of any templating system, or none at all; the first release used TT2, and through Ben's efforts, this one will use HTML::Template objects as well as TT2 ones. We're preparing methods to allow interface to a wider array of templating systems, so that virtually ANY templater could be used. We're also implementing the ability to run without templates at all, because they can be cumbersome for some situations, or maybe just don't fit well in a given solution. Maybe you just like CGI and want to use it. Like I said, I want to encumber programmers as little as possible.
The same thing goes for data validation; there's a handful of commonly referenced data validation modules on cpan. Which one do you like? Maybe your data validation occurs when data's submitted to the database, and you don't need any perl for it at all, you just want to pay attention to the db handle's return value. It'll be your gig.

Of course, I am not against any other module. I don't think any of them are dangerous, or badly written, so plase don't read anything into this project. In fact, personal experince tells me that Jesse Erlbaum has a thriving and active interest in the CGI::App community, and he's always been responsive to his user's needs.

So what is the strength of the Framework concept?

• determine state
• perform data validation
• template preparation
• preprocessing
• template display
• post processing

It still sounds quite a bit like CGI::MxScreen, but maybe less prescriptive about what other modules it works with. Being flexible can be tough, because an application framework that doesn't assume anything about choice of template tool or validating tool can't offer as much automation to the developer using it. Maybe you can find a good middle ground.

As far as CGI::Application goes, I don't see why you don't just extend that rather than starting from scratch. It seems like it wouldn't be hard to change CGI::App to work with TT2. The HTML::Template integration is minimal.

The reason I originally started trying to do something like this was that I'd found CGI::Application but didn't like that it didn't have either integrated validation or integrated support for template management. Then I found HTML::Template and it's another piece. Then there's Data::FormValidator, etc.

It seems like everyone wants to solve a piece of the problem without necessarily solving the entire problem (or providing a good set of glue to make all the pieces fit together). This module provides templating, that module provides for individual field validation, this other module provides for flow control.

That's all wonderful (and I'm really not getting down on the contributions of others), but with a large collection of modules, none of which do the entire task, and potentially non-trivial glue to write, it made me think there had to be a better way.

I'm definitely not saying that this (Framework.pm) is the better way. I'm going to sit and take a long look at the modules mentioned, but I think I'll be able to stand by my previous statement that most take a piecemeal approach to this problem.

Heck, maybe the right way to solve this is to come up with the glue that binds an orthogonal yet complete bunch of the pieces together. Dunno... That wasn't the swamp I was looking to drain. :-)

> I'm going to sit and take a long look at the modules mentioned

And when you do this, please also look at www.extropia.com and the other frameworks mentioned on princepawn's homenode (like OpenFrame, OpenInteract, OpenThought, CGI::XMLApplication and so on).

The tools I mentioned are really meant as glue code between the various pieces. They're trying to do the same thing you are. It might be more efficient to look at these and choose the one that's closest to what you want, and then add the additional features you need to it. That will give you an instant set of testers for your work.

I would suggest giving OpenInteract a look as well.