How does Dancer handle forms? How do other such frameworks do it?

[Cody Fendant]

This is more of a "solve an argument" thing than an urgent enquiry. But I was having an argument with someone about how a framework would handle a form with checkboxes … how does Dancer does basic CGI as in reading key-value pairs from an HTTP GET/POST? How do other frameworks do it? Surely not by using CGI.pm, which everyone is scornful about? But also just as surely not by rolling their own?

I've opened Dancer.pm and I'm not seeing any CGI modules. Same for Dancer/HTTP.pm — where should I look?

[Your Mother]

Look for _parse_get_params and the post counterparts and methods (which should probably have been plain utility subs/functions in my mind method overhead for _url_decode and friends is silly and it's “private” anyway so…) in Dancer::Request. Rolling your own is fine if you know what you’re doing. Which is not an endorsement. I for one am not as taken with Dancer as many others seem to be. :P

[davido]

Often with a framework such as Mojolicious, you totally ditch the CGI paradigm of restarting the script on each request. Many times you will just put the script up in a daemon mode and let it listen, or behind the Hypnotoad preforking webserver, or run it plugged into the Plack middleware.

Mojolicious exposes the request's GET or POST data via the "param" method. It's well documented at Mojolicious::Lite GET/POST parameters. There are also 'req' and 'res' accessors that allow you to get information on the request, and make settings for the response. If you want to explore Mojolicous, start with Mojolicious::Lite, which is a very convenient starting point for lightweight apps. The documentation is pretty easy to get started with.

[Anonymous Monk]

They all do it the exact same way :) the modules are different, but its all the same 100%

my $object = CGI->new; ## NOTHING TO GRUMBLE ABOUT HERE

They're all basically HTTP::Requests (HTTP::Messages), you get access to headers, you get a request object, which gives you access to params , or to file uploads ,or to the raw content if you want it

They're all the same everywhere in every programming language; the details are different (app->cookies versus request->headers->cookie ... lots of overlap and shortcuts )

Some advanced features include dumping the request to harddisk for lower memory usage and providing a filehandle to this temporary ...

similar advanced feature is stream-from-disk instead of loading in memory for responses

Mojo::Message::Request, Dancer::Request, Dancer2::Core::Request, Catalyst::Request, Apache::Request, Apache2::Request, Plack::Request

Unlike CGI.pm (which does a bunch) most of these have a corresponding ::Response object and various helpers, but thats about all the difference

All the frameworks give you a request object

All the frameworks want you to give them a response object

CGI.pm is very flexible but its about print not return for responses; if you use CGI::Application framework you get the same organization (request/response, no printing)

Most folks reflexively badmouthing CGI.pm are extremely ignorant about it

If you're using CGI.pm and following CGI to mod_perl Porting. mod_perl Coding guidelines you're 98% modern , only 2% away from using any "modern frameworks" which have a response object

[sundialsvc4]

Whether they use CGI; or not, is really not the point.   The HTTP protocol is by now well-understood.   So are the ways of decoding it such that the gathered data (a) will be correctly gathered in all cases, and (b) will be presented to you in an easily-manageable format ... maybe a hash containing scalars or lists in each bucket ... maybe accessor-methods.

One might wish that the frameworks, themselves were standardized, i.e. that they presented a consistent API to those who would like to write code that is “compatible with Everyframework,” but I don’t think that we will ever see that.