Keeping content and presentation together for big projects
is generally a serious design mistake, and the ugliness of
the advanced layouts should be a tip-off to you that you are
being bitten by it.
See Re: Re: Re: Re: Code Critique for a basic list of reasons why it is a
good idea to separate content from presentation. (And if
you read my response later in the same thread you will see
that I don't merely advocate templating as a religious
persuasion.) | [reply] |
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."
| [reply] |
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] |