Hey, everyone! I'm going to be Derek's mentor for his GetPaid GSOC 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.
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 [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
-~----------~----~----~----~------~----~------~--~---
