some thoughts on Derek's GSOC
Brandon Craig Rhodes
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.
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.
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. 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.
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.
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.
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 bra...@rhodesmill.org http://rhodesmill.org/brandon
Michael Dunstan
<bra...@rhodesmill.org> wrote:
>
> Hey, everyone! I'm going to be Derek's mentor for his GetPaid GSOC
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"
/>
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.
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.
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.
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.
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.
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 bra...@rhodesmill.org http://rhodesmill.org/brandon
>
> >
>
Michael Dunstan
Derek Richardson
On Fri, Apr 3, 2009 at 11:20 PM, Michael Dunstan
<michael...@gmail.com> wrote:
>
> On Sat, Apr 4, 2009 at 5:17 AM, Brandon Craig Rhodes
> <bra...@rhodesmill.org> wrote:
>>
>> Hey, everyone! I'm going to be Derek's mentor for his GetPaid GSOC
>
> Yay!
registered as a potential payment processor and allows choice. That
seems even more end-user oriented to my naive judgment. Thoughts?
>> 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.
it could be done in parallel.
>
>> 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.
could be done in parallel if there is interest.
Michael Dunstan
<derek.k.r...@gmail.com> wrote:
> Hmmmm. I was thinking a configlet that sees everything that is
> registered as a potential payment processor and allows choice. That
> seems even more end-user oriented to my naive judgment. Thoughts?
Yup - allowing the user to pick their own payment processor would be great.
I don't currently have a good feel for what kind of changes that might
require to the core to support that.
Minor technical note - I think the browser layer technique might still
be of value in that model too. In that case I guess you would interact
with the browser layer API at the request level. Different requests
would pick up different browser layers based on the users payment
processor selection. Obviously that only apply after the user has
actually selected a processor.
>> 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.
>
> Thanks for the explanation of the basic varieties!
Oh yeah - another component for input on this is finding all the
various overrides that are used by the various payment processors. A
list of those has been started here:
http://code.google.com/p/getpaid/issues/detail?id=167
Though since that list was started a few more payment processors have
been added to the getpaid ecosystem.
--
Michael Dunstan
David Glick
> On Mon, Apr 6, 2009 at 11:46 PM, Derek Richardson
> <derek.k.r...@gmail.com> wrote:
>
>> Hmmmm. I was thinking a configlet that sees everything that is
>> registered as a potential payment processor and allows choice. That
>> seems even more end-user oriented to my naive judgment. Thoughts?
>
> Yup - allowing the user to pick their own payment processor would be
> great.
>
> I don't currently have a good feel for what kind of changes that might
> require to the core to support that.
>
> Minor technical note - I think the browser layer technique might still
> be of value in that model too. In that case I guess you would interact
> with the browser layer API at the request level. Different requests
> would pick up different browser layers based on the users payment
> processor selection. Obviously that only apply after the user has
> actually selected a processor.
I think the GetPaid configlet already incorporates payment processor
selection. It just doesn't work properly because of the use of view
overrides in some processors.
David
Michael Dunstan
> I think the GetPaid configlet already incorporates payment processor
> selection. It just doesn't work properly because of the use of view
> overrides in some processors.
oops - I thought the new suggestion was to offer selection to the shopper.
--
Michael Dunstan