this pattern of HTML form + cgi processor is inferior to using a modern JavaScript async call to send the data to a RESTful API endpoint (like /cgi-bin/rob/gfgf with method=DELETE, encoded as application/json
I do have to stop and take issue with this. A key principle on the Web is graceful degradation. Nearly all interactive browsers support forms, including such oddballs as Lynx and other curses-based browsers that do not require a graphical display. You can have a fancy JavaScript frontend, but you should still have basic forms — perhaps the CGI form processor translates the form submission to a RESTful request — for browsers that do not support JavaScript and users that choose not to run JavaScript.
That last note is a legitimate choice no matter how many hipster Web developers whine about it — nearly all client-side Web security exploits in the modern era have depended 100% on JavaScript to run. Disabling JavaScript is very much legitimate security advice, unless of course you want your files ransomwared.
| [reply] |
nearly all client-side Web security exploits in the modern era have depended 100% on JavaScript to run[citation needed]
| [reply] |
| [reply] |
Thank you for your help. Also thank you for the suggestions. I am writing a really basic application, so I ended up using the old CGI and HTML::Template. I am on a shared server which does not allow too much. It comes with CGI enabled and I think installing and using the Mojolicious framework is not possible. I had a look at the framework, and it seems to me that it would need quite an investment in time to set it up and learn it. I would be ready to use some Mojo modules to replace CGI. However, I could not find any way to perform in Mojo the same basic things I am doing in CGI, so to say, out of the box. Am I wrong?
| [reply] |
I am on a shared server which does not allow too much. It comes with CGI enabled and I think installing and using the Mojolicious framework is not possible.
Yes, even you can use CPAN - Mojolicious is pure-Perl, with no non-core dependencies, which makes it especially suitable for installing in situations like these.
I had a look at the framework, and it seems to me that it would need quite an investment in time to set it up and learn it.
Well, for really simple CGI applications, sure, you could use e.g. CGI::Simple. But I've been using Mojolicious more and more recently, and I think it's good even for really simple stuff, and IMHO learning it is definitely worth the investment because you'll get so much more functionality out of a seemingly simple app. To get started, have a look at Mojolicious::Guides::Tutorial. I also have several examples on my scratchpad.
However, I could not find any way to perform in Mojo the same basic things I am doing in CGI, so to say, out of the box.
This is the equivalent to the code you showed:
#!/usr/bin/perl
use Mojolicious::Lite -signatures;
get '/' => sub ($c) {
$c->render(template => 'index');
} => 'index';
get '/delete' => sub ($c) {
my $token = $c->param('token');
my $key = $c->param('key');
my $usr = $c->param('usr');
$c->render( text=>"Token: $token - Key: $key - Usr: $usr" );
} => 'delete';
app->start;
__DATA__
@@ layouts/main.html.ep
<!DOCTYPE html>
<html>
<head><title><%= title %></title></head>
<body>
%= content
</body>
</html>
@@ index.html.ep
% layout 'main', title => 'Hello, World!';
<div>
%= form_for delete => ( method=>'get' ) => begin
%= hidden_field key => 'gfgf'
%= hidden_field usr => 'rob'
<div class="form-group">
%= label_for id => 'Your token'
%= text_field token=>'Default', class=>"form-control", id=>"id", r
+eadonly=>undef
</div>
<div class="form-group">
%= submit_button 'Delete', class=>"btn btn-primary"
</div>
%= end
</div>
Though you should probably change get '/delete' to post '/delete' and method=>'get' to method=>'post'. This script will work both when started via e.g. morbo script.pl, and as a CGI script automatically. | [reply] [d/l] [select] |
>Am I wrong?
I am not super familiar with Mojo. And I do not think you're wrong. But you can use something like CGI::Application in your .cgi right away so that you can start organizing your code for a more "modern" paradigm. With some fiddling of the apache configuration (assuming), you can look at using actual routes via CGI::Application::Dispatch.
It is true and relevant that changing your mindset is probably the hardest thing to do overall. I can see how on a shared hosting system where you don't have access apache configurations or to determine what is listening on port 80/443, that you would have the very real limitations you're describing. Go with what you know, but know that even in your environment you have some options.
| [reply] |
perlfan:.cgi is a pain to maintain (use Dancer2 or Mojo)
silly statement as both mojo.cgi and dancer.cgi are both .cgi
| [reply] |
Care to explain the nuance or technicality you're using to sully my helpful and informative answer? I think in the context, it's clear what I am talking about.
| [reply] |
Care to explain the nuance or technicality you're using to sully my helpful and informative answer? I think in the context, it's clear what I am talking about.
It is clear the statement is not valid, no nuances required.
| [reply] |