Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor get_gateway, get_integration logic #111

Open
tuxcanfly opened this issue Jul 23, 2014 · 1 comment
Open

Refactor get_gateway, get_integration logic #111

tuxcanfly opened this issue Jul 23, 2014 · 1 comment

Comments

@tuxcanfly
Copy link
Member

Right now, get_gateway and get_integration are a bit magical. If we want foo backend, we're looking for app.gateways.foo.FooGateway in all installed apps. In addition to being inefficient, it has a chance of causing unintended consequences due to layout of other installed apps. The only benefit is that we allow users to define custom backends by following the above convention.

Instead, I propose we should have a setting similar to CACHES e.g MERCHANT_GATEWAYS with key being the gateway name and value being the dotted path to the gateway class. Then get_gateway could simply load the class pointed at by the path. This will allow more flexibility in creating and laying out custom backends.

Same goes for integrations.

@tuxcanfly
Copy link
Member Author

Backward compat: we can have a default for MERCHANT_GATEWAYS that points to the existing classes, so I as far as I can see, this change will be backward compatible. We'll need to display a DeprecationWarning for custom gateways to notify them to update to the new way of adding custom gateways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant