Re: CGI::Tiny versus undefined parameter/form field

I've been trying to "upgrade" one of my scripts from the now-outdated (so I am told) CGI.pm to a more modern implementation that I had hoped would be mostly a "drop-in" replacement for it: CGI::Tiny.

What portion of the CGI::Tiny documention said to you "drop-in replacement"? Looking at that documentation, compared to my CGI.pm experience, it seems a completely different philosophy.

Something like CGI::Simple, on the other hand, specifically says as the first sentence of the DESCRIPTION: "CGI::Simple provides a relatively lightweight drop in replacement for CGI.pm." It has all the parameter-handling interface, without any of CGI.pm's poorly-designed and deprecated HTML-generating code.

If your goal is a drop-in replacement, I would suggest going with CGI::Simple (or just using the non-HTML portions of CGI.pm -- because while the HTML generation portion is deprecated, and the whole module is now non-core, CGI.pm and the Common Gateway Interface it implements still works and is still available and useable); then you can spend your learning-effort in something like Template Toolkit for improved HTML generation, instead of learning a new philosophy for handling the parameters and everything.
If you want to learn something new and different on the interface side, then CGI::Tiny might do it; but looking briefly at its documentation, I would not have come up with a SSCCE like hippo was able to do here, so it might not have the easiest learning curve for someone who still has the CGI.pm thought processes...
But if you're going to bother trying to learn a whole new philosophy anyway, why not go with one of the "big 2" rather than CGI::Tiny , which I have rarely-if-ever remembered seeing mentioned here. For me, when I tried to expand my horizons a couple years ago, I was able to learn from the Mojolicious::Lite documentation sufficiently to get apps of similar complexity to the ones I used to do in CGI.pm, so that is what I personally use when doing a new script for my hobby website; I am not an expert by any means, but I can get some simple endpoints. (Something that I don't think is clear enough in their docs: if you have an old-fashioned CGI-based web host, like many of the shared hosts out there, you don't need to do any of their fancy stuff with the "server" side of things; you just put your Mojolicious::Lite-using script in your cgi-bin folder or wherever you used to put it with a CGI.pm-based app, and it will work the same.)

CGI::Alternatives does a really good job of showing you an old style CGI+HTML-from-CGI.pm, then showing you the equivalent application in CGI.pm+TemplateToolkit (which would be virtually identical to CGI::Simple + Template Toolkit if you wanted to go down that path), and then in Mojolicious::Lite, Mojolicious "full", and Dancer2.

Comment on Re: CGI::Tiny versus undefined parameter/form field

Replies are listed 'Best First'.
Re^2: CGI::Tiny versus undefined parameter/form field by Polyglot (Chaplain) on Dec 12, 2022 at 15:29 UTC
Yes, I think you are correct: `CGI::Tiny` is fundamentally different. It won't work for me. Believe it or not, I have used (or tried to) `CGI::Simple` before. It won't work on my Mac, which is where I develop. So "Simple" didn't live up to its name for me. I don't use CGI for much, actually. I use it for the form inputs, and that's about it. So if that is not the portion of its codebase that landed it on the "deprecated" list, I guess I should be fine. In any case, for now at least, I've given up on the CGI::Tiny. It's a tool for someone else. I'm back to good old CGI. One thing that irritated me with CGI is that it only recognizes the "name" attribute of an element, and not its "id". But I guess I can live with assigning both, one for the JS, and one for the CGI. It just seems a shame to have to repeat so many names--fattens the code, and uses more bandwidth. Blessings, ~Polyglot~	[reply] [d/l] [select]
Re^3: CGI::Tiny versus undefined parameter/form field by pryrt (Abbot) on Dec 12, 2022 at 15:41 UTC
It won't work on my Mac, which is where I develop. So "Simple" didn't live up to its name for me. I find that hard to believe, given the green Darwin column in cpantesters report, unless the test suite is not sufficient. But since I don't have a Mac (and haven't used one since they looked like this), I won't be any help in that regard.	[reply]
Re^4: CGI::Tiny versus undefined parameter/form field by Polyglot (Chaplain) on Dec 12, 2022 at 15:56 UTC
Well, I have an older Mac, and too much on it to dare trying to upgrade. My Perl version is 5.12--and from the chart you linked, CGI::Simple is compatible with 5.16 at the earliest. I guess that's the deal right there. Blessings, ~Polyglot~	[reply]
Re^5: CGI::Tiny versus undefined parameter/form field by marto (Cardinal) on Dec 12, 2022 at 16:01 UTC
Re^6: CGI::Tiny versus undefined parameter/form field by Polyglot (Chaplain) on Dec 12, 2022 at 16:27 UTC
Some notes below your chosen depth have not been shown here


No such thing as a small change
	PerlMonks