The form classes should not contain any controller logic. Move that into the adapter, or even better, into a new controller class. Figure out how to wrap responses like redirect-iframe.
Thinking out loud:
GatewayPage
- Controller for UI.
- Any reason not to pull in the resultswitcher logic?
- handleRequest
- Reads from POST and SESSION
- Performs UI side-effects.
GatewayAdapter
- Should have processing-specific controller logic, the sequence of API calls to make.
- initiatePayment
- Call validation here?
- Returns PaymentResponse object.
PaymentResponse
Encapsulate and decouple adapter initiatePayment response, can be mapped directly to a UI action to present to the donor.
- recoverableError -> Refresh form, optionally displaying validation errors.
- gatewayInteractionRequired -> Redirect to gateway, with GET params.
- gatewayIframeRequired -> IFrame would ideally be handled by template engine simply refreshing and iframeUrl toggles conditional display.
- unrecoverableError -> redirect to failure page, for example after a credit card transaction was declined.
- success -> redirect to Thank You page
Notes
K4-713 reminds us to not short-circuit the orphan slayer, which relies on an existing mechanism to capture success status, etc.
Implementation
- https://gerrit.wikimedia.org/r/#/c/185598
- https://gerrit.wikimedia.org/r/#/c/189133
- https://gerrit.wikimedia.org/r/#/c/189134
- https://gerrit.wikimedia.org/r/#/c/189136
- https://gerrit.wikimedia.org/r/#/c/183630
- https://gerrit.wikimedia.org/r/#/c/189615
- https://gerrit.wikimedia.org/r/#/c/189153
Documentation
http://www.mediawiki.org/wiki/Extension:DonationInterface#GatewayForm