You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After using get_class a bit into the plugin, I think something doesn't work well: get_class, from Django Oscar, look at oscar.apps.* package first. If plugin users try to extend adyen in their project (say in myproject.apps.adyen), it does not work well:
Creating only myproject.apps.adyen.scaffold is not enough, because calls to get_class will raise import error because there is no such thing as oscar.apps.adyen,
Plugin users will need to also create myproject.apps.adyen.facade and so on. If new sub-module are added to adyen, plugin user's project will be broken with each new update.
Solutions
Plan A: write custom get_class
The first option would be to write a custom get_class, say in adyen.utils.get_class. I'm sure we can reuse parts of oscar.core.loadings functions, but that still a lot of works (more tests, more possible bugs...).
On the other hand, that would be quite convenient since get_class is a widely used in Django Oscar. This might be more convenient for Django Oscar users, since they would be used to it already.
Plan B: write build_FOO_BAR methods on Scaffold, Facade and Gateway
Something I already tried to do in recent commit such as 4c28ea6 to allow one to build the PaymentReturn and PaymentNotification handlers without overriding more than 1 or 2 methods.
It would mean to add at least Scaffold.build_facade and Facade.build_gateway, to make sure one can simply override few classes. That might be enough for most case.
What to do now?
I can not take a decision right now, I need to think a bit more about that first. Both solution are interesting, but both come with costs.
The text was updated successfully, but these errors were encountered:
After using
get_class
a bit into the plugin, I think something doesn't work well:get_class
, from Django Oscar, look atoscar.apps.*
package first. If plugin users try to extendadyen
in their project (say inmyproject.apps.adyen
), it does not work well:myproject.apps.adyen.scaffold
is not enough, because calls toget_class
will raise import error because there is no such thing asoscar.apps.adyen
,myproject.apps.adyen.facade
and so on. If new sub-module are added toadyen
, plugin user's project will be broken with each new update.Solutions
Plan A: write custom
get_class
The first option would be to write a custom
get_class
, say inadyen.utils.get_class
. I'm sure we can reuse parts ofoscar.core.loadings
functions, but that still a lot of works (more tests, more possible bugs...).On the other hand, that would be quite convenient since
get_class
is a widely used in Django Oscar. This might be more convenient for Django Oscar users, since they would be used to it already.Plan B: write
build_FOO_BAR
methods onScaffold
,Facade
andGateway
Something I already tried to do in recent commit such as 4c28ea6 to allow one to build the
PaymentReturn
andPaymentNotification
handlers without overriding more than 1 or 2 methods.It would mean to add at least
Scaffold.build_facade
andFacade.build_gateway
, to make sure one can simply override few classes. That might be enough for most case.What to do now?
I can not take a decision right now, I need to think a bit more about that first. Both solution are interesting, but both come with costs.
The text was updated successfully, but these errors were encountered: