in reply to Re (tilly) 2: OO CGI vs. function-oriented
in thread OO CGI vs. function-oriented

One of the modules that we are using, which I hope to get on CPAN someday (can't right now cause of work restrictions.) is a Persistance mechanism for CGI. Basically a state machine. It's for heavyweight apps. (Some 30 or 40 screens.)

The nice thing about tieing the form generation to the code is that because it generates all the forms, we know what parameters to expect and what they should contain, even how many values they can provide all transparently. (Even files), There is no form validation at all as it's all handled through the object. If the user doesn't supply something, it rolls back state automatically and tells them what they need to do. (We might eventually build a templating system around it which would give us the benefits of both, just not a big priority right now.)

You pretty much can't break it. Usually the only thing required to use this on a script that uses CGI is to change the use statement and the call to new and you gain most of the benefits.

We use a parser to generate the form code from html which let's us leverage non-programmers for the UI.

These won't be used by a lot of people so the extra weight is well worth the trade for simplicity and speed in development.

For many applications, I would agree with you but I think sometimes it makes a lot of sense. Plus if we have to migrate it to a new machine it's a matter of setting up one module and one script and where done.

-Lee

"To be civilized is to deny one's nature."
  • Comment on Re: Re (tilly) 2: OO CGI vs. function-oriented

Replies are listed 'Best First'.
Re^4: OO CGI vs. function-oriented
by Aristotle (Chancellor) on Jan 28, 2002 at 18:22 UTC

    A proper templating module will allow you to do all these things very easily. HTML::Template even which in my opinion is far from the be-all end-all templating module can be tied to CGI to provide the same value defaulting of form elements that CGI offers with its HTML generation functions.

    I consider an immense benefit of templates that the algorithmic logic of the application is never influenced by any output format concerns, the values just get stuffed into a data structure and the template pulls them out at will. For example, let's say I suddenly choose to change the display of a table of records to show the records vertically, rather than horizontally. All I have to do is change the template.. which is bound to be quicker than changing code to accomodate for this would be because a good templating language is geared towards data presentation - a specialized tool for a specific job.

    And if you want the installation ease a single module provides, there is nothing to stop you from storing the templates eg. as values in a hash. You might do something like my $templates = do "templates.pl";, where templates.pl contains { a => 'single', anonymous => 'hash' } block.

    Makeshifts last the longest.

[reply]
[d/l]
      For most people and applications, templates are fine. In my situation it wouldn't work. The forms parameters themselves are mangled on the fly in such a way, that I would have to make my own parser (or use an existing one), and then create another layer to perform our magic. If I need to make a change to the HTML, it takes me a minute using an HTML to CGI.pm converter so changes are almost as fast.

      Anyway, the point is it doesn't always make sense and TMTOWTDI.

      -Lee

      "To be civilized is to deny one's nature."
[reply]

In Section Meditations