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

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

Replies are listed 'Best First'.
Re: How does Dancer handle forms? How do other such frameworks do it? by Your Mother (Archbishop) on Feb 15, 2014 at 03:04 UTC
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	[reply] [d/l] [select]
Re: How does Dancer handle forms? How do other such frameworks do it? by davido (Cardinal) on Feb 15, 2014 at 06:13 UTC
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. Dave	[reply]
Re: How does Dancer handle forms? How do other such frameworks do it? by Anonymous Monk on Feb 15, 2014 at 06:22 UTC
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	[reply]
Re: How does Dancer handle forms? How do other such frameworks do it? by locked_user sundialsvc4 (Abbot) on Feb 16, 2014 at 13:29 UTC
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.