Thank you so much for your helpful feedback
A few question about them if you don't mind...
If you want to support older perl versions...
This is something I haven't looked at yet. I have looked at what version of the dependencies are required which are v0.014 of HTTP::Tiny and v2.00 of JSON::PP. 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?
Searching for attrs in your code I noticed something strange: your methods get_intent get_intent_id get_ids all starts with my ($self, %attrs) = @_; I do not understand: only get_ids is called with arguments. Then (but I do not looked to it closer) why these attrs are not incapsulated inside the main object?
You have highlighted a typo and a shortcoming in the clarity of the documentation!
get_intent, get_intent_id and get_ids (not get_id as the documentation says!) all take the optional parameters reference and email (users may or may not want to use these parameters depending on their use case). Only get_ids optionally takes two other parameters: public-api and format</i>. Controlling the output format between JSON and text is only relevant with this method. The <code>public-api is needed by this method but not by others and needs to be passed in either here or at instantiation. I imagine users will pass both keys to the new method but having the option gives users the choice.
Internal usage of HTTP_HOST and the alike should be documented. I dont recall the whole thing, but document it. They are always used by every server? Only by some?
I'm really glad you picked this up!
I had to do quite a bit of research to find what to do here and I still didn't come up with a definitive answer...this is why there is a TODO at the top of the code to make this more robust and why it checks for callback URLs in the constructor. Within my own environment I have historically used SCRIPT_URI but every now and then it disappears for reasons I don't understand - CGI environment variables seem to be bit of a dark art so I have deliberately used ones that seem to be standard. I don't have an instance of IIS to test it on.
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.
It appears you are using CGI as all your example use it: in 2021 one might expect some example at least in Dancer2
Internally we use a bespoke decoder of query strings and form data so I had to pick something generally available. I picked CGI because I thought it was core (it isn't any more), I know the (basic) syntax and it is simple to understand. Perhaps Dancer2 would be better in the examples but I only put the examples in to show how easy this module is to use and to give people a headstart.
I dont get why your module ends returning some html
Thanks - I shall improve the documentation to explain this better
In reply to Re^2: [RFC] Module code and POD for CPAN
by Bod
in thread [RFC] Module code and POD for CPAN
by Bod
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |