Re: HTML In CGI Scripts.

[Cody Pendant]

The real point, as so many people have said, is that if it's only you, and it's working, then who cares? The moment you've got designer(s) working on the HTML or similar workflow issues, you've got trouble.

I get the impression that the from-worst-scenario-to-best progression in Perl/HTML interaction is like this:

1. Using hundreds of horrible print statements, all of which neeed to have all the quotes escaped
2. Using "print qq" instead
3. Using HERE documents or subs
4. Using your own templating system
5. Throwing your own templating system away and using HTML::Template

Signed,
Nearly Ready To Move To Stage 5

---

“Every bit of code is either naturally related to the problem at hand, or else it's an accidental side effect of the fact that you happened to solve the problem using a digital computer.”
M-J D

[Trimbach]

To your list I'd add:

  3.5.   Print using CGI.pm's HTML generation

Each method (well, except for #1. Yech.) has it's place, and they all work, but I think you've definitely captured the evolutionary aspect of this topic. :-)

Gary Blackburn
Trained Killer

[Cody Pendant]

You're right of course. I realised that later.

But looked at another way, it's almost on its own list. It doesn't mix HTML and Perl at all. You get purity at the expense of no longer being able to see your HTML as HTML.

Mind you, somewhere recently, Merlyn posted (boasted) about his script which reversed the process and turned HTML into CGI.pm data structures.

Can anyone come up with that link? It's certainly an intriguing Third Way of approaching workflow -- get your designers to come up with HTML, slurp it into CGI.pm, then throw it away? Given valid code it's not unreasonable... Hmmm...

---




“Every bit of code is either naturally related to the problem at hand, or else it's an accidental side effect of the fact that you happened to solve the problem using a digital computer.”
M-J D