|Problems? Is your data what you think it is?|
Re: Web application frameworks / experience with CGI::MxScreenby princepawn (Parson)
|on Nov 18, 2001 at 23:03 UTC||Need Help??|
Well, one thing you might want to look at it support levels. Raphael Manfredi (author CGI::MxScreen ) seems to not have a lot of time to answer questions and he doesn't have a mailing list setup with anyone else who can help in his place. I don't always get answers back from him and certainly don't get them back quickly. For example long ago, I asked him: "what will MxScreen do when you have to hit a screen in the middle of the application cold? MxScreen seems to create a state machine of multi-screen page flow with the assumption that you start at the beginning and then always move either forwards or back from there... people like to bookmark URLs and return and the fact that mxscreen uses post data (i am reaching here, I have forgotten) makes this common task impossible.
Besides that, when you talk CGI::MxScreen and HTML::Mason you are talking two very different ends of the spectrum. With Mason, you embed your logic either in your HTML page or in a small perl-HTML "component" which you embed in your page. This is what is known as the "inline" approach. This tight-coupling of Perl and HTML would seem to make it difficult to change the look and feel of a website substantially without losing all of the associated logic. However, Mason advocates site industry-level success to the contrary.
Even so, however, an unavoidable shortcoming of the Inline approach is that it does not give the HTML designer WYSIWIG pages. Furthermore, it robs the power of re-use inherent in programs such as Dreamweaver from the designer and makes this a programming task. Thus for a web site company which places emphasis on visual fine-tuning of pages with close interaction between high-level management and user-experience engineers, the Inline solution will hamper such workflow.
On the other hand, the Inline solutions do offer you a "one-stop-shop" for any web application task you might want to handle - error handling, common-look-and feel, re-use, sessioning, logging, and caching all come right out of the box with either HTML::Mason or HTML::Embperl and both of these products have very active and very supportive and very large user bases. And, because both products have been in development for more than 3 years, they are both well-debugged and ready for critical system deployment.
A younger, but perhaps more open solution following the inline development work cycle is OpenInteract. Again, the support level is strong. This product is also a bit more open-ended. While supplying all of the same features as either of the above, it does so by building on major CPAN modules for each of its cornerstones. For example, instead of a proprietary templating solutin, OpenInteract uses Template Toolkit.
Turning to the "meta-html" solutions, with any of these, HTML page maintenance by non-programmers (HTML designers) is 100% and the solutions to templating are 100% non-invasive. The most mature product in this stable is HTML::Template. However, it's maturity has not led to a stabilization of feature set. Recently it added a small pseudo-language for expression processing HTML::Template::Expr and even more recently, it added a Just-In-Time compiler HTML::Template::Jit which compiles template to C language for 4x speed improvements. While the latter is just a performance improvement, the former is adding to the extra things you might have to learn when learning HTML::Template
HTML::Template also supplies a flexible set of caching options.
It has been around for at least 2-3 years as well and the base module HTML::Template is most likely completely bug free.
However, as the HTML::Template docs say, it only does one thing and does it well and fast. You will have to strap together from CPAN a system for the other aspects of web application development. You might choose CGI::Application for CGI page reuse (this module has some surprising hypocrisy in its design. It boasts that it is webserver and database server agnostic. Yet it is not agnostic with respect to templating system - it requires HTML::Template. to my mind, there is no need for a system for multi-modal page use to require a particular templating system. This, coupled with lack of return emails from the author make this a less-than-attractive solution for any part of an open system). You will need something for logging Apache::Session and so on and so forth.
The other recent entry into the meta-html templating world is my own HTML::Seamstress.
And be sure to check my home node for what I believe to be a comprehensive list of web application frameworks.