HTML In CGI Scripts.

[elam]

Howdy all, I was perusing some of the threads today and noticed one thread which claimed that putting html inside a script was poor programming practice.

I *always* put html inside my scripts, usually as a subroutine, so its out of the way. I've occasionally used templates and then brought those in as a filehandle, and inserted code with markers, but this seems awkward to me.

For instance, I usually have a headers() subroutine, to print my css and javascript as well as a content() subroutine, through which I may pass values to be placed in the html. I work for a very small business, and as such, I am the only web programmer and have learned everything in a vaccum. So, I'm curious as to what methods you guys(and gals) use.

thanks,
Elam

[jonnyfolk]

I use HTML::Template quite a lot and I find it very easy to use and very effective. The advantage of using such a system is that you don't need to change the script every time you make changes to the web page.

However if you are the only person developing scripts/web pages then as far as I know there is no official ban from putting HTML into your script (though previous similar conversations on this site might give that impression).

If you haven't tried HTML::Template, though I suggest you practice with it as it really is a very good, flexible option. The Author has put up a web page to explain it - I suggest you take a look at that before you get started.

Update: Altered links.

[dws]

I'm curious as to what methods you guys(and gals) use.

It depends. For throwaway scripts, I might put HTML inline using HEREDOCs, or I might embed a trivial HTML template after __END__. For anything other than throwaway, I tend to use HTML::Template, which allows the HTML to be edited separate from the code.

Two big problems with mixing HTML and code are:

1. Non-coding HTML designers are shut out. They can't edit the HTML without risk of breaking code.
2. Developers are usually marginal designers, at best.

[The Mad Hatter]

johnnyfolk covered most of it, but I'd like to point out Template Toolkit if you want to use a very powerful templating system. I use it just about whenever I need to template anything, and it works great.

If you ever work in a team, or have someone else doing the web design work, you will want (and need) to seperate the code from the presentation.

[blokhead]

I asked a very similar question a long time ago. Following the advice of the respondents, I quickly learned HTML::Template and have never looked back. Basically, the most important advice is learn a templating system. You will need it sooner or later.

Putting the HTML outputting code in a subroutine is the first step. If you've gotten this far, you probably realize that HTML interspersed with code can get pretty nasty. But eventually, you will need functionality more complex than just variable substitution into your HTML skeleton. At this point, instead of reinventing this very common wheel, learning a templating system will save you a lot of grief. There are several good ones out there.

And if you ever get serious about CGI scripts (as in, coding for money), you will eventually be working with designers. Take it from me, you do NOT want them opening your Perl code to tweak some HTML!

blokhead

[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

[nysus]

Ditto to everything said above. I mix Perl and HTML all the time. I've used HTML::Template and to be sure it's pretty simple and cleaner. But most of the CGI scripts I write are nothing more than interfaces for other Perl programs that won't be used by anyone but me so therefore I just don't have a real need for HTML::Template. But for fancier/more complex layouts and designs, I'd definitely recommend HTML::Template so you can use an HTML editor like Dreamweaver. Coding HTML by hand can really suck for heavy duty HTML.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff";
$nysus = $PM . $MCF;
Click here if you love Perl Monks

[MrCromeDome]

*grins* Somehow I get the feeling you're referring to this node. . . ;)

Personally, I'm very fond of HTML::Template for the sites I do. Most of my sites are written to be used by multiple clients, and by using templates, I can completely change the look and feel of the site without changing any code. I still have what I consider to be an annoying tendency of mixing a lot of CGI.pm methods with HTML::Template code though - but I don't typically work with a designer (which, I think, would help me almost completely transition myself over to templates). There's a lot you can do with HTML::Template, some of which I really need to learn how to do. I'm so used to having CGI.pm generate HTML for me at times that I can't quite think outside the box I've built for myself.

I use CGI.pm to generate HTML for anything quick and dirty that I need to get done. There's no real HTML in my scripts, but effectively non-programmers are prevented from changing the appearance of what those scripts present.

There's nothing wrong with the approach you've selected (TIMTOWTDI!). Only issues I see would be if (like in the situation I describe above) some non-programmer type needed to modify the appearance of your site. Depending on how your own functions are written though, it may not be much of a worry for you.

Hope I didn't ramble too far off topic for you ;)

Cheers!
MrCromeDome

[derby]

Lot's of good points others have made. Just one note, lots of people will say by using templates, you can have designers work on the HTML and you as a dev can concentrate on code. While I think that's great, I think the even greater power is the ability to easily re-skin a site. Combine multiple templates with some well structured CSS reliant html and it becomes very trivial to re-skin a site.

Right now, I have such a site up and running. Basically the back-end is XML, then a combination of a very simplistic mod_perl handler sitting on top of a CGI::Application app that uses HTML::Embperl to provide different skins based upon configurations. The mod_perl handler inspects the url, reads a config file based on url parameters and then jams the appropriate params into the HTTP stream (embperl templates, XSLT stylesheets, CSS stylesheets, other data ...). Sounds complicated but the neat thing is the CGI::Application is free of lots of conditional code. The only real conditionals are built-in default templates and stylesheets.

-derby

[Anonymous Monk]

I have never used HTML::Template so I can't really say much about it. But I do use Text::Template a lot in my CGI scripts. For me it only took about five minutes to learn and it is very flexible.

[WhiteBird]

I am a one-person team, doing both the design and coding for my company's Intra- and Inter- nets. I started out using HERE documents within my cgi scripts. I like the convenience of having everything contained in a single program, and since I don't have anyone else involved it's worked out ok.

However, things change, and the 2 sites are getting larger and perhaps someday I'll have help. I'm currently re-building our Intranet site and since I'm touching everything anyway, I decided to convert some of my old code to HTML Templates.

Initially, I was frustrated with my efforts. While there is documentation available, most of it struck me as being less than instructive. The examples seemed simplistic and not in-depth. I think most of it was written from the perspective of coding, not combining code and design. I persisted though, and now I think I was trying to make things way too complicated.

I did a super search and found an HTML::Template Tutorial and another node on Loop Context Style with HTML::Template. Things seem to have clicked into place and I think I'm on my way to becoming an HTML::Template convert. I made progress today and converted 2 scripts in short order. It gets easier from here. While I can still see good reasons for keeping everything tidy in one script, I can now see other good reasons for pulling it all apart. I think it all depends on what your needs are. I do recommend learning to use Templates, though, as it just adds another option to your toolchest.