[Handel] credit card processing questions

[Christopher H. Laco]

charlie Bowman wrote:
> TreeTribes is the site I'm working on.
> 
> Now its starting to come together.  I need to create a
> package TreeTribes::Authorize that I would put in
> TreeTribes/lib/TreeTribes/Controller/Authorize.pm.  
> It would be as follows.  My questions follow the
> package
> 
>   package TreeTribes::Authorize;
>   use Handel::Constants qw(:checkout);
>   use base 'Handel::Checkout::Plugin';
>   use Business::OnlinePayment::SomePaymentProcessor
> 
>   sub register {
>     my ($self, $ctx) = @_;
> 
>     $ctx->add_handler(CHECKOUT_PHASE_AUTHORIZE,
> \&process_credit_card);
>   };
> 
>   sub process_credit_card {
>     my ($self, $ctx) = @_;
> 
>     ...online payment code here...
> 
>     return CHECKOUT_HANDLER_OK;
>   };
> 
> 1. Is this correct?  The init sub runs first then the
> register sub is called by default so that the phase
> can be associated with the proper sub routine in this
> package.

The concept is correct, but I think you'll have problems with the
namespaces. Handel happens below the Catalyst level, and when it loads
plugins from a namespace, it will try loading all of the available modules.

To load TreeTribes::Authorize as a checkout plugin, you would have to
set HandelPluginPaths (or HandelAddPluginPaths) to TreeTribes. It would
attempt to load all and register all TreeTribres::* modules as checkout
plugins, and that's probably not you don't want.

If it were me, I would make all of your Handel checkout plugins
TreeTribes::Checkout::Authorize, etc. Then set HandelAddPluginPaths with
TreeTribes::Checkout.

Keep in mind, you're Catalyst controllers will probablty never use your
checkout plugins directly. Instead, their probably just calling
Handel::Checkout->new->process().


> 2. next is the setup function to do any setup work you
> need to do.
> 2. the next sub routine to run is whatever sub you
> have associated with the phase.  You do this with
> add_handler.
> 3. teardown is the phase where you put your
> housekeeper. (it cleans up any messes)

The workflow is this:

1. Handel::Checkout->new
2. All plugins in HandelPluginPaths are loaded and new() is called.
3. For each plugin, init() is called during new().
4. Plugins that subclass Handel::Checkout::Plugin, plugin->register is
called. Others are ignored.
5. plugin->register calls $ctx->add_handler as many times as needed
6. $checkout->process gets called
7. plugin->setup is called on each plugin
8. all plugin handles are called, in phase order from @phases
9. plugin->teardown is called on all plugins.

For each additional call to process(). 6-9 happen again.

#2 and #3 are why you should put your checkout plugins in a seperate
namespace. Yu would wan't non-plugin modules to get loaded and have
their new() methods called for no good reason. I'm looking at a way to
prevent this in Module::Pluggable.



> 4. Where do I put this package?  Would it go into
> TreeTribes/lib/TreeTribes/Controllor/ ?

package, or just the plugins?

> 5. currently I haven't created packages for authorize
> and deliver.  How does Handel::Checkout handle these
> missing plugins?  I'm assuming it just pretends that
> it recieved CHECKOUT_HANDLER_OK.

Well, if there are no plugins, none get loaded, none get register, no
handlers are called.

So, for each phase that has nothing to call, nothing get's called. :-)

The upside to that is that even if process thinks if should run all
phases and you only load a plugin for one phase, that's all that runs.

-=Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.rawmode.org/pipermail/handel/attachments/20051209/23e10c41/smime.bin