There's more than one way to do things | |
PerlMonks |
Re^3: [RFC] Module code and POD for CPANby Discipulus (Canon) |
on Apr 14, 2021 at 15:31 UTC ( [id://11131279]=note: print w/replies, xml ) | Need Help?? |
Hello Bod > Do you think I should support Perl versions older than v5.10 given that Perl v5.12's 11th birthday was 2 days ago!? If I decide not to support versions prior to v5.10, does the declaration need to go in the module or just in Makefile.PL? I dont think :) This is up to you. Some ancient systems still run perl versions with mustache and beards. Not being my opinion so much relevant, I assume 5.10 or 5.14 as my own personal backward compatibility limit. That said I suppose you must put it in both place, but probably Makefile.PL is enough being the first thing run during installation. My last module has it stated twice:
I suspect the first one directly aborts the installation (as the file does not compile) and the second can/should generate a report. The redundance does not hurts me. > take the optional parameters reference and email .. Here also I'd put some check from a banal existence of a @ to the usage of Regexp::Common::Email::Address > I don't have an instance of IIS to test it on The code is meant to run on IIS? I have made something with it and is a pain. Every other solution is better also handling HTTP requests by hand with pen and paper :) Eventually Apache can run on windows, some plack servers too. I'm a windows sysadmin: my best wishes. > CGI.. Well.. sincerely seing CGI example can make people fly in horror. Anyway I think no new projects use CGI nowadays. There are valid alternatives and mainly Mojolicious and Dancer2. Being in your cloths I'd propose a CGI example as the last one or ones. Queryin parameters is easy and readable with Dancer2
> Having said that, I cannot imagine a situation outside of initial testing, where the end user will not want to send the customer to a different page depending on whether they paid successfully or not. So cancel-url and success-url would be explicitly set. Reasoning a bit I dont like the solution. Your module should only do the operation needed to interact with this Stripe. I'm not a serious web dev but I think you should avoid it. In Dancer2 or Mojolicious you have the default route / and is the same of your SCRIPT_NAME +/- I suspect will be a pain refactor this part after the module is in production: rethink it if needed. > $attrs{'error'} = ... In the constructor your code returns only the last one error set. Then I prefere undef $attrs{error} over setting it to an empty string in the rest of the module. L*
There are no rules, there are no thumbs.. Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
In Section
Meditations
|
|