use these examples to think about checkout customization

[Brandon Craig Rhodes]

In my email a few minutes ago, I talked about a "general solution" to
the problem of the checkout process, that would go beyond the stop-gap
measure of just adding a half-dozen new plug-in points that payment
processors could select.

To think about this idea more, let's think through what it would be like
if payment processors, shipping calculators, and so forth, were all the
"same sort of thing".  This would mean that there would be just one way
of getting the whole checkout process, as GetPaid defines it, and then
adding a customization, and that payment processors, shipping
calculators, and so forth, would all just use that one language or
mechanism to describe their customizations.

To make this concrete, let's imagine the ways that people need to change
the checkout process - both us, when we write payment processors, and
also Plone integrators, that might be told by site owners that GetPaid
would be great if there could just be "one more field...".

GetPaid would start things off by defining:

 1. BaseCheckoutProcess

    This would define, to make this a small example:

    A "checkout" button view to be shown beneath shopping carts.
    An "addresses" form that accepts the billing and shipping address.
    A "credit card" form that accepts your credit card number.
    A "test" authorize(), capture(), and refund() method.
    "Thank you" and "whoops, you were denied" pages.

Given that "Process", here are some imaginary customizations that might
be made to it, written in plain text rather than any kind of Python-ese
or ZCML:

 2. AuthorizeDotNet

    "inherits" from BaseCheckoutProcess

    Re-defines authorize(), capture(), and refund() so that they
    actually talk to AuthorizeDotNet.

 3. PayFlowPro

    "inherits" from BaseCheckoutProcess

    Re-defines authorize(), capture(), and refund() so that they
    actually talk to PayFlowPro.

 4. Google Checkout

    "inherits" from BaseCheckoutProcess

    Re-defines that very first "Checkout" button so that (a) it looks
    like a Google Checkout button using the right logo and everything,
    and (b) the button now redirects the user to Google Checkout.  Also,
    re-writes the final pages so they make sense to people returning
    from Google.

 5. PxPay

    "inherits" from BaseCheckoutProcess

    Re-defines the "Review and Pay" button in the middle of the checkout
    process so that it looks like a pretty "Check out with PxPay" logo,
    and so that it redirects the user off-site when clicked.  Also,
    re-writes the final pages so they make sense to people returning
    from Google.

 6. "Multiple Payment Processor" Processor

    "inherits" from BaseCheckoutProcess

    This one is fun, because it is a meta-customization that takes two
    or more checkout-wizard customizations as its arguments.  You could
    give it any list of items 2-5, above, as its argument.  It then
    provides the services of a normal checkout wizard, except that,
    quietly, as each step progresses, it checks the next step to see
    whether any of its arguments has customized that step differently
    from any of the others.  If not - if, say, it's advancing to the
    shipping page, and none of the processors that have been selected
    bother to customize that page, then it will just show it.  But if
    the processors it's governing have made "competing" customizations
    of the same step, then the user is presented with a screen asking
    which processor they want to use.  Once they have chosen, they are
    only shown views from that processor for the final steps of the
    process.

But, of course, as I outlined in my last email, there might be
customizations that people want to "turn on" on their GetPaid site that
have nothing to do with which Payment Processor is chosen.  Like:

 7. Shipping Customization

    "inherits" from BaseCheckoutProcess

    This edits the shipping form to be different, like Chris and Josh
    needed that time.  A store owner might want to combine this
    customization with any of the other customizations listed above!

Okay!  Think through these example customizations, and think about
whether you know a mechanism by which our own payment-processor code,
and integrator form-customization code, could describe them so that they
could be executed and run.
   
What would the mechanism be, I wonder?

 * Normal Python sub-classing, with some way to reach into sub-views of
   the whole checkout process, and subclass them, too?

 * Some tangled web made of new ZCML directives, combined with the
   endless localized customization of some named views?

 * A special declarative language for customizing forms and processes?

 * Could this be done, not with subclassing, but with normal Python
   functions which are given a mutable description of the checkout
   process that they then adjust and change dynamically?

 * Some people would imagine something like a WSGI stack here (but not
   really WSGI, but something like it), where the checkout wizard is
   written as a callable layer, and each customization "wraps" calls to
   a checkout wizard "beneath" it but modifies the forms and data coming
   through to add fields, change buttons, or whatever.  This would make
   it obvious, by the way, how to do something complicated like (I hope
   you're using a fixed-width font here):
                                                 ----> AuthorizeDotNet
                                                /
   --> Custom Shipping --> Multiple Payment  ---
         Field Filter       Processor Filter    \
                                                 ----> PxPay

   See?  The MPP filter asks *both* of the layers beneath it for what
   the next step should look like, and can just compare to see if either
   one has customized that step.  And, whatever the payment processors
   do, *if* the shipping field ever gets returned by the MPP (which, for
   example, it won't, if Google Checkout is available and the user
   selects it and gets sent off-site before the shipping step), then
   the top-level filter will add its field to the form on the way out,
   and take care of the extra field as the form is the submitted.

   This is probably slightly crazy, but might help us think about the
   problem of "customizing a form" in a different way that makes it
   clearer what should happen if, say, there are three different ways
   that the form needs to be customized because of boxes that the store
   owner has checked.

That's enough ideas from me for a Saturday evening, I think!  Does
anyone else see anything promising in here?  Any single, clean, unified
way - hopefully that would build upon some existing Plone libraries I've
not been lucky enough to have heard of yet - that we can write *any*
customization to our checkout wizard so that the customizations can be
combined, selected, and compared?

--
Brandon Craig Rhodes   brandon@...   http://rhodesmill.org/brandon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpaid-dev@...
To unsubscribe from this group, send email to getpaid-dev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---