Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re: CGI Benchmarks

by ColonelPanic (Friar)
on Jan 24, 2001 at 04:16 UTC ( [id://53846]=note: print w/replies, xml ) Need Help??


in reply to CGI Benchmarks

I find CGI.pm to be EXTREMELY useful. I use it in every cgi script I write. Particularly, the header() and start_html() routines are great time savers. And it's much easier and safer to handle input from the browser with CGI.pm. Learn how to use it--it's easy and you won't be wasting your time. On the other hand, I often tend to use plain print statements for printing out the html tags in between:
I do this: print "<h1>blah blah blah</h1>"; instead of the CGI.pm way: print $query->h1(--I'm not even sure of this syntax--);
I don't have anything against the CGI.pm way, but why learn another syntax when I already know HTML? I don't see any particular advantage of the latter way, not even a savings in typing. If I'm missing something here, somebody please tell me.

When's the last time you used duct tape on a duct? --Larry Wall

Replies are listed 'Best First'.
Re: Re: CGI Benchmarks
by AgentM (Curate) on Jan 24, 2001 at 09:00 UTC
    Aaah! But you ARE missing out on something! Using the CGI tag shortcuts you don't have to write out the tags and the string is enclosed in Perl's parentheses rather than difficult to mind-parse tags (stay in Perl if you're using Perl ideology). Also, You'll be able to organize the HTML more clearly- including indentation (automatic for Perl and NOT for HTML in good editors), better spacing, and attribute clarity. Especially if you have long lines of attributes, you'll save yourself days of mind-boggling debugging if you use:
    print HTMLtag({-attr1=>'bob', -attr2=>'Sammy Snake', ....}, 'Sammy Snake's Page');
    rather than raw HTML. Table generation is also extremely useful in the CGI module, allowing you to logically group your attributes and indent them rather than arbitrary HTML spacing. If you read through the CGI docs, you'll also learn about a cool "design your own tag" which is easily created in the use CGI; line. That way, you can name an arbitrary new tag (which CGI may not support by default) with arbitrary attributes. In short, using CGI to its fullest can only result in beneficial and "easier-on-them-eyes" programming techniques. It definitely worth reading up on. M$ is mentioned in the tutorial. Btw, the syntaxes are to-the-point and rather obvious.
    print TagWithNoAttrs('Howdy Ho Neighbor!'); print TagWithAttrs({-attr1=>'Blue',-attr2=>'orange'},'How many Preside +nts does it take to screw an intern?');
    CGI also supports a method whereby you simply pass string arguments and thus implicitly print the attributes in a logical order without declaring what they are, but I tend towards the more explicit method. Have fun with CGI, though. That's what its main purpose is. (OK, so maybe that's arguable.)
    AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
      You have a point there. The CGI.pm version does look a lot cleaner. For table generation, also, I would probably look into the module in more depth. However, I disagree with the point about debugging. I find that errors in printing the HTML are almost always readily visible. If an attribute isn't correct, you will instantly notice that that header isn't centered, or whatever. A simple view source will generally pinpoint the problem.

      When's the last time you used duct tape on a duct? --Larry Wall
        But using CGI, it's very unlikely that you'll have ANY broken tags. Anyway, you're right about the debugging. First, I would check what's wrong with the HTML source, THEN go to the perl and isolate the problem. Of course, if you can eliminate broken tags AND misspelled attributes, then you're debugging woes are kept to a minimum. CGI gives you the benefit of both.
        AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
Re: Re: CGI Benchmarks
by skeight (Novice) on Jan 25, 2001 at 03:52 UTC
    That is actually the current way that I am doing it, except for the fact that i have "data files" that hold the html.
    ie.
    open(HTML,"index.da1"); while(<HTML>){print $_;} close(HTML);
    then I'll have whatever dbi stuff I have to do then do the same thing for "index.da2" and so on. Do you think that's slower than just having all the html code "embedded" into the perl?
      Sorry I am a bit late on this thread.

      Without seeing the whole context of your example, I am prone to say that you are delving into serious overkill. Why use a Perl script to deliver the contents of a text file without doing anything to it? HTTP is perfectly capable of doing this for you. :)

      open(HTML,"index.da1"); while(<HTML>){ # do something to $_ print $_; } close(HTML);

      Yes, that is slower than embedding the code, because you have to open a file, as well as print each line. But, if you are actually doing something to each line, or even just a few special lines - then it is a viable solution. Of course, if you are just testing the waters, then that is certainly understandable.

      But that's not my point - database access will make your speed concerns with your current program seem very trivial.

      Which brings me to my real point - "embedding" HTML into a Perl script really only has one major issue in my books - MAINTAINABILITY!!

      If you are the only user of this script, don't worry about it. But, if you are coding for the good of a larger project, one that has HTML content writers and programmers - then you will want to seperate the HTML from the Perl.

      Generally, Perl programmers don't want to have to concern themselves with the details of HTML layout - and HTML writers usually can't understand Perl code.

      My first real assignment after graduating was a Cold Fusion project. My HTML was embedded in the Cold Fusion files like a cancer - and when it came time to tweak the position of this or that graphic, guess who had to do it? Me!! If I was smart, I would have seperated the HTML code completely, so that the HTML writers could tweak without having to be scared that they would screw everything up.

      If you really want to put your HTML code in separate files, look into HTML::Template, it is well worth your time.

      Jeff

      L-LL-L--L-LL-L--L-LL-L--
      -R--R-RR-R--R-RR-R--R-RR
      F--F--F--F--F--F--F--F--
      (the triplet paradiddle)
      
        First off, I am the only person working on this script and chances are no-one else will ever maintain it other than me, so I can pretty much do whatever I want

        Here's an example of what I am doing:
        ... print "welcome ",$username, "your email address is ",$email; open(HTML,"index.da1"); while(<HTML>){print$_;} close(HTML); print "your manager is ",$manager; open(HTML,"index.da2"); while(<HTML>{print$_;} close(HTML);
        basically I print out some information from the database, then a whole wack of html code (index.da1) and then print out some more info from the database then a whole wack more of html (index.da2).

        obviously this is a very small example compared to what I am actually doing, but the basic idea is there.
        do you think it would be quicker just to have all the html 'embedded' into the perl? even though this would make the script well over 7500 lines long? Does that make a difference (file length)?

        skeight

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://53846]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2024-04-19 03:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found