inline On Fri, Apr 3, 2009 at 11:20 PM, Michael Dunstan <[email protected]> wrote: > > 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!
Provisional yay on being accepted. ;) >> 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. 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? >> 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. Thanks for the explanation of the basic varieties! > >> 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. Yes, I think this is out-of-scope for gsoc, though interest would mean 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. I also like this but see it as similarly out-of-scope for gsoc. Again, could be done in parallel if there is interest. >> >> -- >> 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 -~----------~----~----~----~------~----~------~--~---
