On Sat, Apr 4, 2009 at 5:17 AM, Brandon Craig Rhodes
<[email protected]> wrote:
>
> Hey, everyone! I'm going to be Derek's mentor for his GetPaid GSOC
Yay!
> if
> it gets approved, and was just looking at the codebase to familiarize
> myself with the project he's undertaking. My notes - which are those of
> someone looking at the code base for the first time and looking for the
> issues that had been descirbed to me - follow.
>
> ------------------------------------------------------------------------
>
> Derek dropped by this morning and politely pointed out that my goal this
> week ought not to have been to just enjoy reading GetPaid code, but to
> make specific notes about the technical aspects of his GSOC application.
> So I have just looked through the code again to make the following
> notes, which are certainly not a design, but might help give the
> application the technical heft that it needs.
>
> The getpaid/googlecheckout/README.txt file has two complaints in it that
> sound like the source of this GSOC application. The second one listed
> is probably the more minor, so let's tackle that one first:
>
> - Makes use of zcml overrides to integrate with GetPaid. This is a
> sign that GetPaid is not yet sufficiently plugable to support this
> kind of processor.
>
> These overrides are in "override.zcml" files, three of them, in the code
> base, which contain the two following substantive overrides:
>
> <browser:viewlet
> name="cart-actions"
> manager="Products.PloneGetPaid.interfaces.IGetPaidCartViewletManager"
> class=".cart.Actions"
> permission="zope2.View"
> weight="20"
> />
>
> <plone:portlet
> name="getpaid.cart"
> interface="Products.PloneGetPaid.browser.portlets.cart.ICartPortlet"
> assignment="Products.PloneGetPaid.browser.portlets.cart.Assignment"
> renderer=".cart.Renderer"
> addview="Products.PloneGetPaid.browser.portlets.cart.AddForm"
> />
>
> What's the issue here? The issue is that, given the way it's currently
> designed, you can only have *one* checkout wizard known to the system at
> a time. In other words, you *select* which checkout process you want by
> only having *registered* the one you want.
Recently davisagli suggested in #getpaid an alternative to using
overrides that is worth recording here. Basically use browser layers
to switch in and out different payment processors. Use the API from
plone.browserlayer to enable/disable the layer when the payment
processor is turned on/off. Then any payment processor can apply
whatever customisations it likes via a layer attribute in the ZCML
declaration. So the above viewlet would not need to be expressed as an
override. But instead should look something like:
<browser:viewlet
name="cart-actions"
manager="Products.PloneGetPaid.interfaces.IGetPaidCartViewletManager"
class=".cart.Actions"
permission="zope2.View"
weight="20"
layer="getpaid.googlecheckout.interfaces.IGoogleCheckoutLayer"
/>
So that sounds like it is a better alternative than overrides. And I'd
say useful to have that inplace independent of how the checkout wizard
is refactored.
> Obviously, this is tawdry. What we want is to be able to have as many
> wizards *registered* at a time as we want, then have some other utility
> that *selects* which one should be used. That way, instead of having to
> ZCML-activate something like Google Checkout, you would go to the
> checkout wizard selector and select the one you wanted out of the
> perhaps very many that were available.
Yeah - having some explicit support for a several different payment
processor types of integration would be useful. Might be worth getting
a good idea of what the different processors types all look like. For
starters:
(a) Synchronous. Where GetPaid collects all the user details and
payment details and clears the payment details on the spot.
(b) GetPaid collects the user details but does not collect the payment
details. Instead the user is redirected to a different service to
collect the payment details. I think the paypal and pxpay processors
are examples of this.
(c) GetPaid does not collect anything. Instead the user is redirected
to a different service to collect user details and payment details. I
think googlecheckout is an example processor like this.
(d) GetPaid collects user details and provides payment instructions
but but payment is not processed in real time. Instead an invoice is
issued. I dunno if there are existing processors like this.
> Okay, second issue: the .txt file says:
>
> - The GetPaid order manager is not integrated with Google Checkout.
> Google Checkout includes its own order management functionality.
> Although Google Checkout does have a rich enough API that these two
> could be integrated with each other. And there is already working
> integration with the Google Checkout Notification API.
>
> The details of this are a bit more fuzzy to me, but I think that "order
> management" means "keeping up with which things are boxed, which are
> shipped, and which have been returned" and so forth.
Yeah. You can get a feel for that from the Google Checkout
documentation:
http://code.google.com/apis/checkout/developer/index.html#merchant_center_screen
> The idea here
> seems to be that, if you use Google Checkout and want to use its order
> management functionality, then you have to use Google's site to do so,
> because GetPaid can't read back from Google's records about the order's
> state to tell you where each order is in the shipping process.
Well there is nothing preventing GetPaid from mirroring the data or
functionality of the Google Checkout manager. Just that in the
previous spurt of development for Google Checkout that was seen as
unnecessary. There was nothing for the client to win from such a
mirroring.
There may well be use cases where it does make sense to mirror the
data and functionality.
There is a pretty good API to build that mirroring with. The processor
already has basic support for the the notification handling from
Google Checkout. The mirroring would just take that further. I little
technical detail worth understanding is that the notification handling
requires that you have a valid SSL cert for your own site.
There is also support for remotely acting on orders. You can issue
various kinds of commands. See
http://code.google.com/apis/checkout/developer/index.html#order_processing_api
I'm not familiar with the data models of either the GetPaid order
manager or the Google Checkout manager. There may well be some
mismatch at the data model level that complicates the integration.
> This area is much more of a mystery to me; would integration be done
> on-the-fly (pulling from a Google API as you browsed orders in the
> GetPaid management backend), or would Google somehow call back to or
> alert the Plone site so that content items were paced through a series
> of state changes as the order was fulfilled? I can't tell at this point
> exactly what was imagined.
Google Checkout sends notifications to your site. There is an example
of that in the tests. See 'Processor can handle incoming notifications
from Google Checkout:' of
http://code.google.com/p/getpaid/source/browse/getpaid.googlecheckout/trunk/src/getpaid/googlecheckout/googlecheckout.txt#128
There is quite rich palette of notifications. The current
implementation of the processor is only interested in the
new-order-notification so that it can clear the users shopping cart on
successful completion of the payment. It's a small usability detail
for the shopping experience.
See
http://code.google.com/apis/checkout/developer/Google_Checkout_XML_API_Notification_API.html
> Okay! That's some bare technical detail; and it almost sounds like
> Chris's concern is mostly for the first item, which if true would be
> felicitous since that's the issue that's technically the most obvious to
> me.
There is more room for tighter integration with Google Checkout if
that is of interest. I dunno how much of that would be generalised and
of interest to the GetPaid core. For example integrating GetPaid
shipping with Google Checkout shipping. And I think there is a
slightly different Google Checkout API for integration when handling
donations.
> I have a third agenda: I'd like to make it easier to decouple ZODB
> storage from the application logic. Looking over the code, it looks
> like whoever wrote this made the content objects inherit from Persistent
> and then went ahead and wrote many basic methods right there on the
> storage objects. If this were factored off, then GetPaid could be used
> on top of TurboGears objects or Django objects instead by simply marking
> them with an interface saying "this is an order object! use it!" or
> whatever.
>
> --
> Brandon Craig Rhodes [email protected] http://rhodesmill.org/brandon
>
> >
>
--
Michael Dunstan
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
