On Tue, Aug 18, 2009 at 3:21 PM, Brandon Craig Rhodes<[email protected]> wrote: > > Christopher Johnson <[email protected]> writes: > >> Brandon - hopefully that clarifies both the situation with what you >> are trying to do as well as the problem you are trying to address >> (over-dependence on overrides for payment processors) and recent work >> to change the situation (multiple payment processors) :D > > I'm not sure the multiple-payment-processors work helps things any with > external payment processors, but I'll look for the branch that he's > talking about to see.
There has been some work to support external (async) processors at least at the API level. I agree that multiple-payment-processors focuses on a different use case. > But, yes, Michael is talking about the exact same > issue with GetPaid that I'm setting out to address: Yay - that sound great. > it's just turning up > here in a different situation (testing) that the situation that's really > the main concern (running a site in production). Essentially, while I > knew that a site could only have one ZCML setup, I had somehow imagined > that the test suite might have the power to run the normal tests, see > them succeed, and then activate the Google Checkout ZCML just for its > own tests. > > Apparently not. :-) Correct. I don't think the current wiring of the zcml overrides works in a way that lets you run all the tests for all the processors. I think that is a very worthy goal - to be able to run all the tests for all the processors. The bug you found in the googlecheckout processor (in the other thread) demonstrates the need for that. It might be that a rearrangement of the zcml overrides wiring during the tests could be pulled off to achieve that goal. <davisagli> (I think that is who it was) on #getpaid suggested a simple solution to the problem. Use browser layers. Get each payment processor to create their own browser layer. And get GetPaid to swap in the correct browser layer for the currently configured payment processor. A payment processor can then just use the layer attribute in ZCML to do preform whatever customisations it requires. While that very neatly avoids the problem with overrides it does not really provide an API for new payment processors to code against. But that's moving onto a separate problem. The browser layer trick would be useful to have anyway and may well provide a pathway to something more like an API. Though I'm not sure how that would fit in with what is happening with the multiple-payment-processors work. -- 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 -~----------~----~----~----~------~----~------~--~---
