Welcome to the Monastery | |
PerlMonks |
Advantages (boo)by boo_radley (Parson) |
on Nov 22, 2001 at 01:09 UTC ( [id://126858]=note: print w/replies, xml ) | Need Help?? |
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... 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 Section
Seekers of Perl Wisdom
|
|