flask-resty
flask-resty copied to clipboard
4Catalyzer
Figure out a better way to manage "current view" context
In many places, we have to explicitly pass the view into helper classes, e.g. https://github.com/4Catalyzer/flask-resty/blob/438f439e3960118f1c9f0426bc1c0baf5a6424ac/flask_resty/view.py#L295. This is sort of clunky, and we end up passing those around in places where they may be unnecessary.
It would be better if we could bind the view object to helper class instances, or else have some flask_resty.current_view proxy.
yeah. maybe something like
class FooView(...):
authorization = FooAuth() # insert some python magic here that does `self.authorization.view = self`, I am pretty sure it's possible
eg in the view constructor /shrug
it works better if those are all classes, note. otherwise we'd be mutating objects or doing other magical things.
Yeah, marshmallow and WTForms mutate field objects upon instantiation (marshmallow via a Field #_bind_to_schema(field_name, schema) hook). Using classes would be better.
Perhaps deprecate authorization in favor of authorization_class (or authorization_classes if we want to allow a collection like in DRF) which could also support the proposal in #236?
class WidgetView(GenericModelView):
authorization_class = WidgetAuthorization | AdminAuthorization
i'd call it Authorization to make inline defs a bit nicer-looking – class Authorization(FooView.Authorization) reads better than class authorization_class(FooView.authorization_class). we could take the same approach more broadly, though, e.g. with filtering, instead of doing:
filtering = Filtering(
name=operator.eq,
)
we could have
class Filtering:
name = operator.eq
would make it better to extend across views, too
class ExtendedView(BaseView):
class Filtering(BaseView.Filtering):
other_field = operator.eq
I thought magical things are the norm in python (sqlalchemy?) :P I am fine with inlining things but it's a big change in terms of project structuring, in the sense that right now things are separated in modules by types, whereas with this approach they will be separated by functionality
Yeah, I like the inlining idea in principle. Certainly a big change, though could be done iteratively. Also, views.py could get pretty huge...we might eventually want have a module per resource or even per view class.
depends how you use FR, if you are really high in the microservices spectrum, having every view in one file is very convenient. but if we look at our big services (mgmt), that retaliates.