Well, at this point I feel like I am about halfway through the work of re-factoring GetPaid to support all of our current payment processors without requiring overrides - which is to say, I'm nearly done looking at the problem, and about ready to start writing and implementing.
For those who didn't know, by the way, Derek Richardson, a well-known friend of Plone, is very generously funding me to perform this work for the GetPaid community, since it would have been accomplished this summer through his Google Summer of Code work, had he not become ineligible for the program by leaving grad school in order to pursue some bigger opportunities to help people. At this point, I see two ways forward: an "easy" path that I can certainly get done, and another that is more difficult because I do not know quite enough about Plone form technologies at this point to know whether that I'm thinking about is possible. I'll make this short, at least compared to my usual emails. :-) The Easy Option --------------- It would be easy to add a few new plug-in points to the Payment Processor spec so that payment processors could customize buttons so that they send the user off-site at various points in the checkout process. This would merge in well with the "multiplepaymentprocessors" work, since if the store owner selects more than one payment processor, then GetPaid can just (more or less) offer several buttons. There *is* a difference between that work an my own philosophy, since they used a new ZCML directive, whereas I would advocate keeping the information in classes, like normal Python programmers, to make pieces of GetPaid easier to use in other frameworks; but, the mailing list could come to a conclusion on that issue, and a solution generated. The More Complicated Option --------------------------- Here, rather than providing only a few plug-in points for payment processors to provide, we could instead define a payment processor to be "a specialization of the default GetPaid checkout wizard". Of course, when you hear "specialization", then sub-classing probably comes to mind - which would lead to something like "a Payment Processor is a subclass of BasePaymentProcessor that either sticks real credit-card verification in at the end, or customizes one of the forms in the middle to send the user off-site" - but I'm not sure that sub-classing would be exactly the right solution. Why not use subclassing? Well, first - and here my Plone technical knowledge needs help - I'm not sure that a subclass of something is an easy place to put information like: "Okay, this Payment Processor leaves most of the Check-out process the same, but in the first step the Billing Address form needs another field because of the way postal addresses restrictions in East Africa, and then in the third step the 'Finish and Pay' button actually POSTs a form to this offsite payment processor to send the user there." That's some complicated stuff to be squeezing into a subclass definition; can you even customize a normal Plone form by subclassing it? Can you remove fields, add fields, and rewrite the restrictions on certain fields in a subclass? Or are the Plone form libraries not built for easy specialization of a form someone else wrote? (And how is that different between, say, formlib and z3c.form?) And the second reason not to use subclassing: I think that the whole point of this second method would be that GetPaid users often need to do other specialization besides just changing payment processors! This whole email is probably due to hearing Chris Johnson and Josh Kidd describe, on Wednesday, how annoying it was to customize (I think) the shipping-method form for a particular customer. I think they said they had to use a ZCML override, like Payment Processors do! That's annoying. If all I do here is create more plug-in points for Payment Processors, we'll have removed the overrides in those particular spots, but we'll still have the problem that we don't have a general way of creating a specialization of the whole checkout processor that has the power to change or tweak anything, without having to do overrides. A general mechanism that lets you get the whole checkout process, tweak a few things, and have that tweak appear in the store owner's options as "Google Off-site Checkout" or "Extra Warehouse Field in Shipping", would solve lots of problems instead of just this payment processor one. But, it would have to be *flexible*, because a store owner might want to stack a shipping-form modification on top of a billing-address form customization on top of the "multipaymentprocessor" form choosing between two different off-site payment processors that come into play for the last step of the check-out. We would have to have a pretty, site-admin-form-driven way of combining these sorts of customizations. So: should I solve the "small" problem by making more Payment Processor hooks, or look at the "large" problem by looking around to see if Plone supports a customization language or customization procedure that lets you describe changes to an interface, such that (a) they can be stacked together to all be applied to the same checkout process, and (b) compared so that a "multiplepaymentprocessor" can compare two customizations of the checkout wizard and insert a "choose which you want!" screen right before the two processes encounter their first difference? I might come up with a small, more explicit example for the latter so that we can see what is really the complexity of what we're talking about. But, for now, I'm just going to hit "send" and see if anyone has seen anything like this in Plone before. -- 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 -~----------~----~----~----~------~----~------~--~---
