Sounds like a reasonable way to organize things to me, as long as your CGI scripts are quite simple. I wouldn't use that model myself, because I use lots of includes in my templates to provide a consistent look and feel to the application. But if your scripts only needs one template, then the DATA method seems like a good option...

It will also be slightly quicker than an external template, since perl will only need to access one file, instead of opening two.

cees , can you provide anymore info on the DATA method? I use HTML::Template, but sometimes it's overkill. It sounds like this might be simpler/faster/easier.

Thanks.

Um, the DATA method is what we are talking about! You just put your template in the DATA section of your Perl script. I use this all the time for simple CGI scripts and examples i post here at the Monastery - but for anything serious, i use another file for the template. As for your overkill problem, the more you use HTML::Template the less the overkill seems to be a problem.

As for your problem at Re: html template in a perl script, have you looked into Template yet? Kake Pugh has an excellent article over at perl.com: How to Avoid Writing Code that demonstrates how well that Class::DBI works with Template Toolkit.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

If you read the original question again, you will see what the DATA method that I am talking about refers to. It is a method for adding a __DATA__ section to your perl code, where perl will automatically provide this data in the file handle DATA. The above question gives an example of how to use this using HTML::Template.

For more info, check out perldoc SelfLoader for some more info on __DATA__.

- Cees

Template includes in a template is something I hadn't thought to consider. I usually don't include other templates, but I can see how it could become an orginizational nightmare having some HTML in the scripts, and some in templates laying around elsewhere. Good call, I'll keep this in mind!

I would guess that most people who use HTML::Template do it because they have other people who are not perl programmers but need to work directly on the HTML layout -- no one (least of all the non-programmers) would want non-programmers altering contents of perl scripts just to change the appearance, layout or "static" information of a web page. Or maybe programmers have one text editor mode for perl and a different one for HTML, and it's just easier to do these two jobs in separate text files.

If those situations don't apply to you (you alone are controlling the static layout as well as the dynamic content and you handle HTML editing the way you handle perl editing), then this seemingly contradictory use of HTML::Template is simply a way of organizing your own code to be neater, more compact and easier to maintain -- and easier to adapt later on, if at some point you decide to use HTML::Template in the more usual manner, to keep the code and the layout completely separate.

The idea of using HTML::Template to separate the Perl and the HTML makes sense. Programmers work on the Perl, designers work on the HTML. If you are the only one working on what are Perl scripts with a 1:1 Perl/HTML doc relationship then fine.

Although I have used this trick for very simple scripts I find it a dangerous concept for general purpose use at it 're-integrates' the Perl and HTML, albeit in a more maintainable form than using CGI.pm or just using HERE documents.

jdtoronto

Although I have used this trick for very simple scripts I find it a dangerous concept for general purpose use at it 're-integrates' the Perl and HTML, albeit in a more maintainable form than using CGI.pm or just using HERE documents.

What does that mean ? I dont know how separating code and html will be dangerous.

I have successfully used templates for my smaller scripts. There has been times when I had to dump a concise text report or a long html report. I could do that by just switching the templates, without the core part of the script having to bother what kind of report we are going to generate. I thought templates are a boon when doing that. There is also an article in The Perl Review Separating Code, Presentation, and Configuration that deals with this in detail.

-T

I can't speak for jdtoronto, but i am pretty sure that he was talking about keeping the HTML and Perl seperate, but in the same text file - i.e., put the template in the DATA section. I agree that this is nice for small quickies, but for anything serious, you should go ahead a seperate the code and template into two (or more) text files.

So then the question is (again) - why not put the code and template in the same text file? Because you will most likely end up having to seperate them in the long run when scalability rears it's ugly head. (please see 3Re: HTML::Template - complex sites for a technique for dealing with a more complex template structure.)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Well, it is dangerous in the sense that it is only, IMHO, a partial separation of Perl and HTML. As a pragmatic point I consider that the programme and the presentation should 'always be separated when it is reasonably possible to do so'.

The viewpoint I was hoping to express here is that if this technique works for you, then use it. But beware, it is only a half measure and wilst I would consider it appropriate for small or simple applications. I think the original question included a remark about the writer preparing some scripts for a friend where a simple script and a single template were involved. As a method of packaging the script and template where the author is likely to be the one modifying both parts then it might be a pragmatically acceptable alternative.

jdtoronto

-sam

PS: Ignore anyone that suggests you switch to another templating system. HTML::Template has always served me well and I expect it will continue to do the same for you!

- If you keep the template in a separated file, you can drop the template into a browser and look how it looks like.

- If you keep the template in a separated file, you can edit it with an WYSIWYG editor.

- In a CGI enviroment, avoiding to open an extra file will bring a very small performance gain, and very very small if the extra file is already in the OS file cache. Normally, there are some more expensive tasks: forking the process, loading modules, connecting to DB (if any), parsing template, doing some real process...
If you are worried about CGI performance, I would suggest to take a look at SpeedyCGI: mod_perl comparable performance (slower, obvious) under CGI.

José

Fine for simple matters, but what would you do when you need to have access to two or more templates from the same script?

CountZero

In that case you use Inline::Files.

I wasn't planning on making one template for EVERY script, but it does come in handy in many instnaces. For instance I have a lot of utility scripts for editing Berkeley Databases and various other things. These scripts are created as a drop in solution and can often end up just about anywhere. The HTML for these scripts never really changes. All a template really does is adds another thing to cart around with the script.

If you're creating a dynamic page where multiple pages need to retain the same look, then sharing similar templates makes sense. I do what you do quite often with multiple parts, but usually I use server side includes to call perl content. I'm pretty picky on performance, so I often find it's better to have cron run scripts to generate "static" content, or just have a perl script generate "static" content for each change. You can slightly improve security by this method by moving scripts out of harms (hackers) way.

I've never been the sort of guy to make an entire website have a single look, mainly just by section so often I end up designing many more templates. Cutting these pages apart gives you flexibility, but having four template parts gets really messy when you're talking going six html tables deep and spanning multiple template files.

This is often more of an issue with an associate of mine who isn't so CGI oriented. He has a bad habbit of seeing an html page (template) and linking that instead of the CGI script and only later looks at it and sees there's no conetent!