Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Separation of content and code

by Draff (Acolyte)
on Jun 18, 2001 at 11:53 UTC ( #89243=perlquestion: print w/replies, xml ) Need Help??

Draff has asked for the wisdom of the Perl Monks concerning the following question:

Dear all,

I have a question, since I am a programmer. I've now finished my program in perl; actually one of my colleagues suggests splitting the html code into another file like a module, and passing all the info as a hash into that html file and generating another new html file out.

But my perl program contains all the logic to print the html, so I follow the way he wants to split the html code; then I need to put the header, all the functions in perl to print the header where the expiry will be no more, and in that temp file I need to put the .

So should I do it or not? For in my opinion, perl is for the replacement of html; why do we need to split the html code into another file, make a perl file to pass in the server data which needs to be published for the user with hash variable, and finally make out another new html file, and publish the html file indeed the cgi file?

Maybe the question I make a bit confusing; but please write some ideas and please ask about the confusing parts, I will reply.

Thank you

Edit 2001-06-18 10:17 GMT +1 -- ar0n More descriptive title
Edit 2001-06-18 5:17 EST -- Petruchio Added whitespace, corrected grammatical and typographic errors. View source for original.

Replies are listed 'Best First'.
Re: Separation of content and code
by tinman (Curate) on Jun 18, 2001 at 12:22 UTC

    Well, I think your question is a little unclear to me, but I'll try and do a spot of guesswork and shoot in a few directions... just a reminder: try to preview before you submit a question, a bit of punctuation and a few paragraph <p> tags here and there could help a lot

    If I understand correctly, your scenario is that you've written a CGI script, which generates HTML (using print statements or heredocs)..

    Now this posting is a great place to start reading on why you need to put your HTML in a different file.. quite simply, you want to separate your code from your presentation (HTML) because that makes it easier to maintain... if someone asks you to do minor changes to the HTML, then you need to dig through all of your code to find out the place to change, and you could actually break some of your code in the process...

    Another thing, if you separate your HTML into another file, someone who doesn't know Perl well, but who does know HTML could actually figure out what to do, and fix it..

    Another option that I think you mention is to generate an HTML file and display that on the webserver, rather than a CGI script.. (correct me if I didn't guess right).. well, you could do this, but then your content would no longer be dynamic, it would have to rely on your CGI script executing periodically and regenerating your HTML file.. if you need to display something that doesn't change very often, or if it does not need to be customized by individual viewers of your site (for example, a site like Perlmonks has to be customized and dynamic because different users have different views of the content on the site), then generating static HTML pages will mean that the webserver doesn't have a lot of overhead running a CGI script..

    I hope this answered your question.. if you need any clarification or if I didn't answer what you needed to know, please reply on this thread...

      OTOH, has a lot of commands for writing tables and other HTML, so a lot of people including me must be mixing their program logic and their HTML in the same file.

      What if the structure of the HTML depends upon the program logic? I may for instance show data as a table if more than one row is returned, but as a paragraph otherwise.

      I do not believe that it is necessarily better to use templates. Merlyn has an entire chapter on in the 2nd version of Learning Perl, and I don't recall him giving such advice.

        Most template solutions have minimal built in logic to differ output based on program input. (or least I know that Template Toolkit does for sure). However, I only do this when the change is subtle with the overall page keeping much of the same layout; insted it's usually easier to write two different template files if the change is more drastic. Note that still cleans up your perl code, more so than writing two branches of HTML functions.

        But templates are not always the solution in every case. If you have a SSI included script, for example, you only need the minimal HTML that CGI provides. Short, demonstration scripts that aren't really part of a site could easily qualify as well. In addition, if you are building a page that has to be speedy (maybe it's your home page of a million+ hits per day site), a template solution could just slow you down, though if the rest of the site is in template form, it's a tossup. (In general in this situation, your 'entrance' page ought to be statically delievered, which might mean you need to create it every 5 minutes or so from dynamic content).

        But if you are building a site of any magnitue more than a handful of pages, you really ought to be considering templates as to avoid problems with consistent site look after a time.

        Dr. Michael K. Neylon - || "You've left the lens cap of your mind on again, Pinky" - The Brain
Re: Separation of content and code
by Sherlock (Deacon) on Jun 18, 2001 at 15:10 UTC
    All Hail the great HTML::Template! *grin* I don't know if I'd go that far, but I use HTML::Template almost every time I write a CGI script that needs to generate HTML. It has a number of benefits that I find very helpful.

    • Reduces "Code Bloat"
    • Lightens your work load (potentially)
    • Makes scripts more maintainable
    My guess is that some of the other monks could add to this list, but these are the main reasons I use templates to separate HTML from Perl. Let's look at each benefit and I'll do what I can to explain what I mean.

    Reduces "Code Bloat"

    When I'm writing a CGI script, I find that, if I try to incorporate the HTML within the script itself, the script becomes very long and difficult to deal with. Even if I know exactly what's wrong with the script and how to fix it, I might still end up taking some time sifting through my script trying to find that part of my code. You can imagine how much longer it takes me when I don't know just how to fix it. Basically, separating the two allows you to isolate your problems a little easier. If it's a logic issue, look into your Perl script. If it's a display format issue, check out the HTML template file. This way, you're not spending extra time sifting through either one when that's not really where the problem is.

    Lightens your work load (potentially)

    This one may or may not be true, depending upon your work situation. For me, this used to be very true, but not so now. You see, if you separate your HTML from your Perl, other people (that don't really need to know Perl) can edit the HTML in order to make the output "look better" or "display data more readably" etc. This has the potential of taking some of the work out of your lap. If all of your HTML is generated within your script, anyone that wants to change the output is forced to edit your CGI script directly. This can lead to people breaking your script on you or people constantly asking you to change the way this looks or change the way that looks. Either one is a big nuisance in my book. Like I said, this used to be very true for me - I used to work in an office where I could do the real code development and then "hand off" my work to some web designers who were very good at making my work "look good." Most of these designers didn't know much Perl, but if I separated the code from the HTML, they were able to edit the HTML for me and help me out with my projects. Otherwise, I would have been stuck trying to do all of the development and all of the "prettying" work myself.

    Makes scripts more maintainable

    This somewhat relates back to the first point, but I feel that it's different enough to warrant a little extra discussion. Imagine you've just written a large CGI script (we'll say about 1KLOC - that's 1000 lines of code for those scoring at home). Let's assume that about half of that is actually script specifically to generate HTML. Now, imagine (if you're like me, you don't have to imagine very hard) that four months after you've written this large script, something breaks or someone asks for some new functionality. Well, I guess it's time to sift through 500 extra lines of HTML generation code to find your error or, on the other hand, maybe you're sifting through 500 lines of Perl script in order to change a heading to bold in the HTML. Either way, after four months away from your script, you'll probably find that it makes much more sense if you're not trying to piece together the whole thing in one file. You can check out this node to see a detailed explanation of this. I once asked the other monks for help on this topic and that node is what they came up with for me.

    So that's roughly why I like using HTML::Template to separate my Perl from my HTML. I like to isolate the two so that I keep different things in different places. Granted, you can generate the exact same output by putting all of the HTML generation within the Perl script, but this usually turns out to be a headache for me. I'm not sure exactly what sierrathedog04 means when he/she says that you can't format the data differently in different cases. For cases such as those, HTML::Template offers conditionals so that you can display different things based on an if-test (or a series of if-tests). If you're looking for a very drastic change, you can even switch to a different template file within your script to accomodate.

    Hopefully, this helps a little.

    - Sherlock

    Skepticism is the source of knowledge as much as knowledge is the source of skepticism.
Re: Separation of content and code
by Gloom (Monk) on Jun 18, 2001 at 16:27 UTC
    Maybe you can generate XML with you cgis and filter the output with some XSLT filters... this work great =)
    Take a look at XML::Sablotron for process details.
    Hope this helps
Re: Separation of content and code
by voyager (Friar) on Jun 18, 2001 at 18:01 UTC
    One approach in the spirit of seperation of content and code is to collect your data (into one big hash, e.g.) by whatever means, then put all of your HTML-generating code in a sub (that may call other subs).

    This half-way approach removes the need for a templating system, but segregates the HTML code from the business logic, somewhat alleviating the potential to break perl code while changing HTML.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://89243]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (1)
As of 2019-08-21 02:32 GMT
Find Nodes?
    Voting Booth?

    No recent polls found