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 [email protected] 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
