Although I guess I could answer "TIMTOWTDI", that seems like a cop out. I'll try to enumerate my reasons as coherently as possible, so this node may be a bit longish.

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?

I believe that it's in the way Framework's pages will flow : there is a well-defined order that things will occur in.
An application will always have the opportunity to (this is sort of a gloss-over - read the parent node if you want the full details.)

This, in a nutshell, is one of the strengths -- it does what it says, provides a framework for your web app, and not just as a collection of loosely related subroutines and templates, it's structuring makes it unique. If a page has error checking, it'll happen consistently. If a page has preprocessing requirements, you only need to worry about the requirements, and not how to wedge them into the flow of the application, or how to return errors from each of the above phases, or how to handle parameter processing.
So, there are similarities between this and the other modules, yes. Their goals are similar, but I think the execution will be where Framework shines.

In reply to Advantages (boo) by boo_radley
in thread Framework.pm 0.02 by bmcatt

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.