Hi Terrence -- I've been meaning to respond to your post. Hopefully I can make this a meaningful and cogent (albeit late) reply. It's a very complicated topic.
> But what is missing from this strap-together approach? What is > better about it? I know for one that constant look-and-feel might > be better left to an HTML design tool (such as Dreamweaver) when > taking the HTML::Template route. Mason is a server-page system. It is, architecturally, no different from EmbPerl, ASP, JSP or ColdFusion. CGI::Application is what I would describe as an "application-oriented" architecture. Combined with a templating system, such as HTML::Template, it is a complete solution. There are two primary differences between a "server-page" system such as Mason and an application-oriented system such as CGI::Application. First, and most obvious, is that server page systems combine application code and HTML in the same document. Second, but possibly even more significant, is the fundamental desire of all server-page system to make every screen in your site homogenous. There are reasons for choosing both. Here is one *very* rough way, IMHO, to think about it: A server-page system MAY be preferable if: * There is only one person developing the site. * All your developers are generalists -- they are all responsible for both code and HTML design. * Your site has a very homogenous level of interactivity from page to page. An application-oriented system MAY be preferable if: * There is more than one person developing the site. * Your developers are specialists -- some are expert coders, and some are expert HTML designers. * Your site consists of some sophisticated web applications and some HTML content. The way I work predominantly falls into the second category. As a result, I use application-oriented systems. I developed the CGI::Application architecture because I wanted a formal structure for creating web software which was application-oriented. The CGI::Application architecture allowed me to develop web software using tried-and-true techniques, such as Object-orientation and Model-View-Controller. Applying these techniques is not easy to do in server-page systems. To attempt to do so requires bending the architecture into a software pretzel. There are, of course, problems related to using an application-oriented system when the job calls for something else: * If you have only one developer who writes both HTML and code, the forced separation between the two can add addition steps. * If you have to add homogenous interactivity to every page in your site, you may have to invent some system for doing so outside of your application architecture. I have also, from time to time, had to work on a server-page system. It has always been a dreadful mess whenever the requirements of the project do not match the preferred set of properties. The problems I've run into in this circumstance are generally: * The work of programmers and HTML designers collide. A designer will try to make a change which breaks code, and vice-versa. * It is very difficult to design sophisticated applications. Multi-screen applications in a server-page system necessitate "pages" which act as switches. (In CGI::Application parlance, there must be one "server-page" per run-mode.) The result is that code is spread all over the place. "Pages", which are really run-modes of a bigger application, are scattered all over the server, without any benefit. (Under what circumstance would you call "save_new_widget.html" outside of some widget-related application?) It is my opinion that an application-oriented system combined with some light-weight system (possibly home-grown) for adding interactive components to non-application pages is a better solution than a full-fledged, heavy-weight server-page system, most of the time. FWIW, there is no dominant module on CPAN which fills the role of allowing "light-weight components" to be inserted into HTML pages as well as CGI::Application run-modes, but there are some ideas which seem to be getting interesting. One which I'm taking a look at now is Sam Tregar's HTML::Template::Expr. With a little effort this module could be incorporated into an Apache module to provide interactive components which would operate in both HTML documents and CGI::Application modules. I can imagine a new system which would allow you to use the same techniques for light-weight interactivity as you might use for sophisticated applications, without the snarl of combining code in HTML or scattering your application code into dozens of separate documents. I think this would be a fantastic project for the right person. Warmest regards, -Jesse- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
