Mikko Ohtamaa <[email protected]> writes:
> Multiple payment processor branch also should support off-site
> processors.
Agreed!
> IPaymentProcessor interface should have not references to the
> user-inteface or Plone (Products.PloneGetPaid) so that other Zope
> frameworks (BFG, Grok) can use it.
Agreed; if possible, payment processors should simply *provide* views,
they should try very hard to avoid importing and fiddling with views
from the existing checkout process.
On the other hand, I think that our checkout forms need to be pulled out
of Products.PloneGetPaid and put somewhere else - maybe in a new package
named "getpaid.checkout"? - so that other frameworks can use them.
There's no reason that our forms shouldn't be able to travel to other
frameworks, I don't think.
> Well... I thought everything in Plone should be configured through
> ZCML nowadays... are we redesigning the system *again*? ;) ZCML is teh
> shit...
Having looked over some Plone documentation to remember exactly how
Plone people think about ZCML (as opposed to how pure Zope 3 people
think about it, or Grok people think about it), it looks like ZCML is a
way to create an ephemeral object that never exists in Python code. To
(maybe) make the difference clear, let me try writing a single example
registration in two different ways:
1. With a custom ZCML directive:
<paymentprocessors:registerProcessor
name="Off-site Google Payment Processor"
selection_view="google-selection-view"
review_pay_view="google-review-pay-view"
/>
2. With a utility registration pointing to a class:
<utility
provides="getpaid.paymentprocessor.interfaces.IPaymentProcessor"
factory="getpaid.googlecheckout.processor.GooglePaymentProcessor"
/>
class GooglePaymentProcessor(PaymentProcessor):
name = u"Off-site Google Payment Processor"
selection_view = "google-selection-view"
review_pay_view = "google-review-pay-view"
So, what are the important differences between these two registrations?
The most notable feature that I can see is that the first one creates a
"ghost" object that you can't actually import anywhere in Python code.
Clearly it creates something called a Payment Processor, that's made up
of other pieces; but where does this information go? Clearly, into some
sort of special registry - that, if I want to introspect, I have to go
read about and learn the API of and write special, customized code to
interact with.
The second registration, by contrast, creates a registration that merely
*points* at an existing entity that I've already gone to the trouble of
creating in code. This object has a name, "GooglePaymentProcessor";
it's clear where it lives (you could, in another application or in other
code, import it and do things with it); and it can be introspected using
good old-fashioned Python mechanisms that every experienced-enough
Python programmer knows how to use.
I have no problem with having GetPaid use ZCML to register payment
processors. But I would like us to use approach #2, where the payment
processor actually *exists* outside of ZCML, inside of regular Python
code, because:
(a) This makes our classes available to other frameworks.
(b) This means that unit tests can proceed without always having to
start up and run the ZCML and create an object registry, since the
payment processor object "already exists" and can just be imported.
(c) It means that in a distant future, if the Grok methodology ever
wins the day, we can just remove the ZCML and have our classes
auto-discovered instead - since all the real information, about
what views and settings the payment processor needs and so forth,
will already be in Python code and not trapped in XML.
> multiplepaymentprocessor branch should handle those case as well. I
> think it's just matter of having more view hooks available (checkout
> button,etc.).
Having stared at the use cases for a few hours, I finally think it's
safe to agree with you: by providing just a few more plug-in points, I
think we can indeed eliminate all special overrides that currently exist
in payment processor registrations.
> 1. In real-world the payment is done just right before you are leaving the
> shop as the last thing of your shopping experience
> 2. Thus, the payment method shoul be chosen as the last step of the wizard
> because people are familiar with this best practice
>
> To support my rationale, all major webshops are doing the payment method as
> the last choice. If you need to see example, try registering a domain in
> GoDaddy.
The choice between payment processors can only be made as the last step
if both of the payment processors that you are choosing between only
send you off-site for the last step. If one of the choices your store
owner has enabled is Google Checkout with both the address and shipping
info collected off-site, then you have to ask whether they want to use
Google Checkout several steps *before* the last step:
CHOICE
checkout ---> Google Checkout ---> Google Checkout address, shipping, etc
button AuthorizeDotNet ---> @@address-info ---> @@review-pay --> ...
Having sketched out many scenarios, I am now convinced that, when the
store owner has selected more than one possible payment processor for
users to choose between, the checkout system needs to:
1. Look at the possible payment processors.
2. Look up the step on which each payment processor sends the user
off-site (if any).
3. One step *before* that step - which might put the choice on the
cart's Checkout button itself! - ask which payment processor the
user wants to use.
Essentially, the cart will have to be smart enough to "diff" the
available checkout processors, see how "early" in the checkout process
the first difference is, and ask right before it hits that step.
--
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
-~----------~----~----~----~------~----~------~--~---
