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.)
- determine state
- perform data validation
- template preparation
- preprocessing
- template display
- post processing
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. | [reply] |
| [reply] |
Well, agreed somewhat on CGI::Application. To be honest, I hadn't seen either of the other two when I started thinking about this and found boo_radley's version posted here.
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. :-) | [reply] |
> 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).
| [reply] |
| [reply] |
