Dave Rolsky <[EMAIL PROTECTED]> wrote: >On Wed, 17 Jul 2002, Rob Nagler wrote: > >> > Petal lets me do that. If that's not of any use to you, fine. The world >> > is full of excellent 'inline style' modules such as HTML::Mason, >> > HTML::Embperl and other Apache::ASP. >> >> These all work on the assumption that the template is written in HTML. > >Actually, neither Mason nor Embperl are HTML-specific these days. Mason >never really was, and Embperl has become much more generic with version 2, >which is in fact now simply called Embperl. Mason will probably changes >its name eventually as well.
-nod- (As an example of a non-HTML [and potentially twisted] app:) I'm working on our next-generation administrative web application (handles some system account management and other similar things for the University). I decided early on to use the MVC paradigm because the programmers (me) are better at programming the MC part than writing the content for the V part. So, looking at the modules available on CPAN (I'm trying to make maximal use of CPAN), I decided to use the following: Mason (Controller): provides easy management of form values from the client, clean division between sections (init, once, shared, etc.), and nice inheritance. For now, Mason is called from AxKit. TT2 (View): makes it easy for non-programmers to edit XML and embed occasional references to data without having to understand the underlying object model -- views are ultimately called from Mason. I use Data::FormValidator to decide which view to use. AxKit (View): translates the XML to the output device the customer is using. Also can support themes. Allows us to internally structure content in a logical manner that may ultimately aid in building a search engine (for a document repository, for example). Also provides the site a the consistent look & feel. Perl (Model): actual database manipulation is done through Perl modules I think I am using each item in its strongest area. There is no HTML until AxKit sends it to the client. It's also easier to throw a few more CPUs or sticks of RAM at the solution than half-a-dozen programmers that can't write anything customer-friendly or technical writers that can't deal with code. (Of course, one of my other mantras is: Always write for a webfarm.) -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix