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

I've recently been asked to write and article for TPJ about Handel, which has forced me to come to terms with starting the next phase of that hobby...er package. While I've always intended for Handel to be a generic commerce framework, it currently only contains the shopping cart stuffs. There is no checkout code.

I don't want to impliment the world, but I want to allow others to do so if they desire.

I'm thinking about keeping orders just like the cart: Handel::Order and Handel::Order::Item. They're data. Nothing more. Nothing less. Then putting the magic in Handel::Checkout; loading Handel::Checkout::Plugins along the way to handle the various phases of an order. The phase could be:

  1. Initialization
  2. Address Verification (Address Scrubbing)
  3. Data Validation (SKU valid? Can ship part non US location?)
  4. Payment Authorization (Paypal, Verisign, POS)
  5. Order Delivery (Fax, Email, Printer)

Anyone been through a phased design like this before? Is the plugin method for each phase a sound one, or is it just asking for trouble? Is it all for knot and a waste of time? :-)

Update: I forgot one part of my question. If it were you, would you make each plugin have 1 method (like execute or process) and the plugin is added to a specific phase; or would you have each plugin subclass ::Plugin, which had method calls for each phase (like init, validate, auth, deliver)?

Replies are listed 'Best First'.
Re: Phases Of The Spoon
by kvale (Monsignor) on Mar 28, 2005 at 22:36 UTC
    I have no experience with internet commerce, but have programmed plugins before.

    Breaking down the process of checkout into subprocesses just seems like good sense from a software engineering point of view. The real question is should individual plugins deal with one subprocess at a time or should they deal with all of them in one module?

    The answer is that it really depends on the coupling of the subprocesses. If one subprocess depends on the result of another, then it makes sense to deal with both in the same module. But if the subprocesses are independent of each other, it is much simpler to write plugins that perform a single task well. For instance, I would guess that method of order delivery doesn't depend on the payment authorization method; all 9 possible combinations could happen. In this case programming 6 individual modules is much better than creating 9 combo modules.

    Update: fixed a typo.

    -Mark

      True, delivery doesn't depend on authorization (unless auth fails of course, then the whole order execution is aborted).

      However, I was thinking that in mostly rare instances, one would like to have the same package/plugin/module handle more than one phase. Let's say a Handel::Checkout::Plugin::PayPal plugin might handle the address verification, the payment autho AND the order delivery, while another Handel::Checkout::Plugin::AddressScrubber simply does it's best to clean addresses.

      So I guess I answered my own quesiton somewhat. :-)