CGI versus CGI::* modules

[michellem]

Hi fellow monks.

In the course of trying to figure out this issue (which I still think is a strange bug, not a problem with my admittedly lame code), I was perusing the CGI man page on CPAN, and found the following quote:

This module has grown large and monolithic. Furthermore it's doing many things, such as handling URLs, parsing CGI input, writing HTML, etc., that are also done in the LWP modules. It should be discarded in favor of the CGI::* modules, but somehow I continue to work on it.

I've found myself frustrated by the HTML code that CGI sometimes produces, as well as it's lack of XHTML compliance, and a few other issues that have cropped up over time. I have a huge project which depends on CGI.pm at this moment in time, although since I am committed to making the code it generates XHTML compliant, I will have to do something different soon. I was perusing the CGI::* and LWP modules, of which there are many, that seem to do overlapping things. One of the things I'm trying to control in this project is the number of required modules, since it's a generalized, open source project.

So my questions are: how many people still depend on CGI? How many have moved to using the other modules, and have you found that worthwhile? What are the best CGI::* modules to use that replace the functions of CGI? And which are the ones that can generate XHTML compliant code?

Thanks!

[jeffa]

That huge project wouldn't happen to be XINA, would it? ;) I just took a look at some of your source code and see that you use a number of different HTML generation styles: functional CGI.pm, object oriented CGI.pm, here docs, and plain old strings. I know this is a lot to ask, but why not branch off a new version that uses a full blown templating system instead? I recommend HTML::Template because it is not too large, fast, and has no non-core module dependencies.

Note that while you need to take many steps backwards, your new code will be free of embedded HTML, allowing you to concentrate on logic only. You might even be able to completely deprecate xistlyesheeteditor.cgi, for example, because your users will instead be able to supply their own (unless you are holding their hand because they can't write CSS).

Personally, i think XINA is cool, but it could use a serious re-write. There is a lot of repeated functionality in every cgi script that should be abstracted into a module instead (meta data collection, database connection, etc). Also, i notice that you only allow connections to MySQL and PostreSQL databases. If you instead allow the user to specify any DBD module, then maybe other programmers will be willing to port XINA to work with those databases for you. ;) Keep your code modular and marvel at the input of others.

For the record, i still love CGI.pm - but i only use it in conjunction with HTML::Template for any serious production code that i produce. Once i made the "clean break" to templates, managing web apps became a lot easier. (CGI::Application might server XINA well, by the way.) Best of luck to you and XINA. :)

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)

[michellem]

I agree with everything you've said. It does need a serious re-write, I'm a pretty lame coder, and as with most open source projects, the challenge is finding the time to do that. Much of the code is evolutionary. Up until now, I've been busy putting in features that pay the bills, and have only had bits of time to do under-the-hood work, and I also only recently have a second developer on the team (more is welcome!). I'm doing a fair bit of extracting functionality and putting them into modules this summer, so version 0.6.2 or whatever I come out with next will have a number of modules, instead of many of those repeated functions, etc.

One of the strategies I have been thinking of is using templating. XINA now uses templating to some degree, but it's hand-rolled and clunky (to say the least.) I'm trying to find ways to both make it easy for me to use templates, as well as end-users, without too much hassle.

Thanks for the suggestions!

[Willard B. Trophy]

My only complaint about HTML::Template is that its templates break validators/reformatters such as HTML Tidy.

Nothing would make me happier than to be proved wrong on this, though ...
(yeah, I'm an old SGML type. Things that don't validate worry me.)

Update, Aug 5: In an attempt to prevent further XP slide, I have to admit that I hadn't RTFM quite thoroughly enough before posting. In addition to the method given by mbadolato below, there's also the vanguard_compatibility_mode option, which allows you to code simple variables as %NAME%.

--
bowling trophy thieves, die!

[mbadolato]

If you put your template tags in as <!-- TMPL_VAR NAME="foo" --> instead of <TMPL_VAR NAME="foo" > then you shouldn't have any issue with validators or html tidy, I would think. Is that not the case?

[sauoq]

So my questions are: how many people still depend on CGI? How many have moved to using the other modules, and have you found that worthwhile? What are the best CGI::* modules to use that replace the functions of CGI?

As I've never used CGI.pm for output, I'm perfectly happy with CGI::Simple these days. I've found that it lives up to its claim and really is a drop-in replacement. (Thanks tachyon!)

And which are the ones that can generate XHTML compliant code?

I wouldn't look to the CGI:: modules for that. Consider using templates and generating your own XHTML compliant output.

-sauoq
"My two cents aren't worth a dime.";

[chromatic]

CGI has generated XHTML compliant code for years. Are you using a really old version?

I see two good reasons to use CGI instead of something else. One, if you're using its HTML-generation functions in a large codebase, it might not be worth switching. Two, if you want to pass in a blessed filehandle and have it read data from there instead of STDIN, many of the replacements don't handle that correctly.

(Yes, this is a plea for tachyon to release CGI::Simple 0.07 soon! :)

[tachyon]

CGI-Simple-0.071 Ran out of excuses. Don't ask why 0.071 (read Changes). Thanks once again for the patch even if it took a rather long time to apply it. Its got your blessed glob patch, p3p support, a minor unicode bugfix, 0 val cookie fix and some mod perl upload fixes.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[ajdelore]

I think that the biggest plus in favour of CGI is wide distribution and user base. It is pretty rare to find a perl installation that doesn't have it, and of course it is the de facto standard for CGI scripts.

Something like CGI::Simple means a good chance that the user has to install it. This is something you need to consider, particularly if everybody starts using their favorite CGI::* module instead of the standard CGI.

I might consider using one script over another if that script used modules I already have, rather than ones I need to install. (And of course, some don't know how to install modules, or don't have access to do so.)

This is not to say that CGI is the best or only solution, but these are things that I think also merit consideration when deciding what module to use.

</ajdelore>

[jonadab]

Something like CGI::Simple means a good chance that the user has to install it.

Depending on what you're doing, that may not be a real issue, since you may by virtue of your requirements already need some non-core modules. For example, Bugzilla, no matter how it was done, could not have gotten away without at least one non-core DBD module, and practically it really had to have a datetime module as well. (I don't happen to know which one it uses.) If your project has this sort of situation, you can use any module you want that's on CPAN, _especially_ if it's pure Perl, and then create a Bundle:: module that pulls in every module you use. The user doesn't even have to _care_ what individual modules you've used; they just install Bundle::Whatever like your install instructions say, and off they go.

OTOH, if you're only using one non-core module and you can easily avoid it by using a core module instead, by all means, do that.

As far as CGI.pm, I got so disgusted with it after seeing the output of some scripts that use it, that I have never even contemplated pondering the possibility of considering ever using it myself. Maybe the authors of the scripts in question used CGI.pm wrongly, and maybe I'm doing CGI.pm an injustice, but CGI is such a simple thing, it wasn't at all difficult to roll my own solution, which handles everything I need (yes, including cookies, which are stored in a MySQL db; my login/logout box is a self-contained function so the user can log in or out from any page that contains it.), runs in taint mode (using Taint to taint the input after parsing it into key/value pairs), returns the form input as a nice tidy hashref, and produces nicely formatted human-readable output that validates. I thought about distributing it, but there are so many implementations already for this... probably because it's such an easy problem. CGI was designed to be easy to implement.

---

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/

[chromatic]

CGI was designed to be easy to implement.

So was HTML.

How does your hand-rolled implementation handle P3P cookies? While you're adding support for those, have you considered CGI::Pretty?

[hardburn]

I wrote a little about this here.

IMHO, the entire community would benifit if CGI.pm were left behind. Somehow, I've gotten into the habit of putting a use CGI qw(:standard); at the top of every CGI I write, and I really need to get that changed to CGI::Simple or something else. I hardly ever use anything from CGI.pm besides param() (though I really ought to use header(), too), and it seems wasteful to load up that beast of a module just for one subroutine.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

[merlyn]

Well, I disagree. CGI.pm is a great first step away from the hand-rolled solutions, and it's ubiquitous, being a core module.

It also handles cookies, sticky fields, and XHTML generation quite nicely.

I'm not sure what you mean by "beast of a module", since it's also "self-loaded", only compiling the parts of itself that you ask for, so it's really the same as a dynamically readjusting module that has exactly what you want. What more could you ask for?

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

[hardburn]

I agree that CGI.pm is great for getting away from hand-rolled solutions. It may not be perfect, but you could do far, far worse.

Handling cookies is nice, but there again, other modules exist that handle that specifically. Sticky fields and XHTML aren't a concern for me, because I use templates extensiviely for any non-trivial CGI.

That's interesting about the dynamic loading, I didn't know about that.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

[thunders]

I really don't like to have any HTML markup mixed into my Perl code. I highly recommend moving towards something like CGI::Application + HTML::Template. Neither module is core, but both are easily availible on CPAN or through PPM.

Doing it this way for especially complex pages, i can do the initial Mockup in Dreamweaver(yeah yeah i know WYSIWYGs are evil), then simply tweak the template page to my needs. This way your logic and presentation are mostly seperated.

CGI Application has methods for getting at params (I believe it imports CGI.pm's query object.) and It takes care of headers automatically.

[jeffa]

Amen to that, but i don't think that WYWSIWYG's are evil, they are just another form of laziness. ;) I recently used Fireworks and Dreamweaver to create the templates for a website. I was handed two Photoshop files that contained the entire front page and an auxiliary page. I used Fireworks to splice up the images, and (even though Fireworks generates HTML) Dreamweaver to create the HTML. Next, add the template tags, and start coding your design. Honestly, i should mention that i had to use PHP for this site, but i was able to utilize PHP-HTML::Template.

Another simpler (and free) way to start off templates is with HTML Tidy. Forgive my bias of operating systems:

$ echo 1 | tidy -asxhtml > skeleton.tmpl

Of course, remaining XHTML compliant is up to you after that, but shouldn't be hard with tools like validator.w3.org available.
One of the kicks i get out of using HTML::Template (well, templates in general) is that i can atcually switch my "mode of thinking": when i am working on the script/module i think like a programmer, but when i am working on the template i think more like a programmer thinking like a designer. ;)

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)

[herveus]

Howdy!

jeffa wrote: but i don't think that WYWSIWYG's are evil, they are just another form of laziness. ;)

Yo Sappy! c'mere; I need a box
/me stands on box

So-called WYSIWYG web page editors are propagating a lie -- the same kind of lie that Font, Color, and Size menus in e-mail user agents tell. The righteous use manly-man type text editors for their HTML coding. :)

/me steps down from soap-box

yours,
Michael

[mbadolato]

I'll concur on CGI::Application. I'm using it on a project at work now, and gotta say that I'm pretty happy with how simple it makes things. And I've been a big fan of HTML::Template for a long time.

Seeing as I haven't been assigned to any Perl projects at work for close to 3 years i was pretty happy to get this current project. I'm making use of CGI, CGI::Application, CGI::Session, HTML::Template, DBI and a few others. It's refreshing to once again have so many great tools available to me and so simple to use.

Let the PHP fanatics claim "PEAR rocks!"... I've still yet to be impressed with it :)

[Cody Pendant]

A lot of people have said this already, but CGI.pm is XHTML compliant, yes. As of 2.69 it defaults to XHTML.

I want to contribute the secret to getting it not to use XHTML, which I had to search for in the POD recently:

 use CGI qw(-no_xhtml);

---




($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss')
 =~y~b-v~a-z~s;                             print

[glwtta]

I've personally never used any of the HTML generating stuff in CGI.pm, but I do use it constantly for the form processing; I'm looking into transitioning to CGI::Minimal or something like it.

[zakzebrowski]

For the most part, I tend to use an older version of cgi.pm (aka the one that is installed on the machine and hasn't been touched in years) because it works, and the browsers that we are developing for are early versions of ie and netsacape...

----
Zak
Pluralitas non est ponenda sine neccesitate - mysql's philosphy

[Notromda]

I think CGI is outdated. The CGI::* modules filled a good purpose as the concept of interactive web programs gained interest, but today, much more complete solutions are available. Take a look at Apache::ASP I can't say enough about how much easier it is to do things with this.