Thanks for the input, David and Michael! You have helped me progress to the next step in my work, which, as before, can be accessed through the following buildout:
https://getpaid.googlecode.com/svn/getpaid.buildout/branches/brandon-no-overrides I have left alone my "Issue #1" from yesterday, which was the way that GetPaid code finds the current site, and the odd fact that payment processors are site adapters rather than utilities. For the moment I am going to leave all of that alone, because it's a side issue to removing the need for payment processor overrides. So, my actual work today has been to: * Split out the concept of an "ICheckoutWizard" from an "IPaymentProcessor", and explain to both the default built-in on-site wizard and the off-site Google Checkout wizard that they are both "ICheckoutWizards". * Add a field to the "Payment Options" in the GetPaid site settings that lets you first choose what payment wizard you want before letting you choose which on-site payment processor you want. I suppose the latter choice should gray-out if you select anything besides the standard on-site wizard, but for now I'll just let the field's name, "On-site payment processor", remind us that the option is only paid attention to if the "On-site Checkout Wizard" is selected. (Can Plone dynamically gray out fields, anyway? Or would the form have to become a horrendous two-step process to have one field be conceptually "downstream" from another?) * Completely rewrite the way that Wizards provide their checkout button for use in both the shopping-cart portlet and the shopping-cart view. They now both use a new view I've created: <a tal:replace="structure context/@@getpaid-checkout-button">Checkout</a> The view (a) looks up which checkout wizard is currently selected in the site-wide GetPaid configuration, (b) asks that checkout wizard what its checkout-button view is called (and gets back either "getpaid-google-checkout-button" or "getpaid-onsite-checkout-button" depending on which of the two wizards is selected), and (c) then renders that view. It might have been overkill to implement each button as a named view like this; but naming every single view possible seems to be the Plone Way, because it allows other people who use GetPaid to customize the buttons individually if they ever need to. Let me know if this was excessive! :-) * Removed the last remnants of the override views from the Google Checkout package. :-) So, what comes next? First, I will look tomorrow at those "other payment processors" that Michael talked about, that he indicates are kind of in between the two extremes of the built-in payment wizard and the completely off-site wizard provided by Google Checkout. My guess is that these others can probably be accommodated very easily now that a distinction exists that lets us talk separately about pages the user sees (ICheckoutWizard) and their properties, and about the API for checking a raw credit card number (IPaymentProcessor). Also, as I head toward the end of the week, I should start looking at the tests affected by what I've written; now that I'm starting to see what this solution looks like, I can now read through the tests and begin to rewrite them. I think there was another definite step I was considering, but it's late and I'm not remembering it. I'll let you know if I think of it tomorrow. :-) -- 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 -~----------~----~----~----~------~----~------~--~---
