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
Essentially, flump might rely on inheritance a little too much.
Currently we expect users to inherit from flump base classes (either the FlumpView or the individual http method mixins), and then provide their own database implementation that all their views inherit from. We also expect pagination to be provided in a mixin.
For the simplest cases this is fine - you can just create a base class from FlumpView that provides your database layer and you're good to go. But when you want some endpoints to be read only (which is not an unrealistic requirement) it becomes much more complicated: suddenly you only want some of your views to inherit from FlumpView, and others need to inherit from a subset of the method mixins. So you end up having to define pagination & database functionality in mixins, and then each individual view needs to pick and choose which of the mixins it needs and be sure to pull them in in the correct order.
Maybe it's just me, but this seems quite awkward - I'm wondering if we could do better...
The text was updated successfully, but these errors were encountered:
Essentially, flump might rely on inheritance a little too much.
Currently we expect users to inherit from flump base classes (either the FlumpView or the individual http method mixins), and then provide their own database implementation that all their views inherit from. We also expect pagination to be provided in a mixin.
For the simplest cases this is fine - you can just create a base class from FlumpView that provides your database layer and you're good to go. But when you want some endpoints to be read only (which is not an unrealistic requirement) it becomes much more complicated: suddenly you only want some of your views to inherit from FlumpView, and others need to inherit from a subset of the method mixins. So you end up having to define pagination & database functionality in mixins, and then each individual view needs to pick and choose which of the mixins it needs and be sure to pull them in in the correct order.
Maybe it's just me, but this seems quite awkward - I'm wondering if we could do better...
The text was updated successfully, but these errors were encountered: