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
The Registry class and RegistryMixin mixin were added in #207 as a way to simplify retrieval of forms and views, without needing imports. They have since found utility in templates rather than view controllers. This has revealed shortcomings:
All registry callables must accept an obj parameter. This is not ideal and should be configurable, as obj is only strictly necessary for forms. The features registry in particular may (a) want to use positional parameters, with (b) a parameter name matching the content type it's hosted on, so a User.features.foo() may want want its parameter to be called user not obj.
All registry members require callable invocation, with () at the end. The features registry was added for feature flags, to decide whether to expose some functionality or not. While it's currently used for UI-related model queries, it is meant for A/B-type testing, where both True and False results are acceptable. Unfortunately, it possible for a template to accidentally use an {% if obj.features.foo %}, skipping the (), and this will always validate as True and also fail to show as a problem in tests. It should be possible to use a registry callable as a property, with no () necessary.
The results of registry callables are not cached. Caching should be an option, and should use the property syntax (no ()).
Registries do not get along with RoleMixin. As a result, when a RoleAccessProxy is handed to a template, it will either be missing the registry entirely, or will be available raw, with all members accessible. Further, there is no option to cast to a dictionary, to send to the client as JSON.
The text was updated successfully, but these errors were encountered:
The
Registry
class andRegistryMixin
mixin were added in #207 as a way to simplify retrieval of forms and views, without needing imports. They have since found utility in templates rather than view controllers. This has revealed shortcomings:obj
parameter. This is not ideal and should be configurable, asobj
is only strictly necessary for forms. Thefeatures
registry in particular may (a) want to use positional parameters, with (b) a parameter name matching the content type it's hosted on, so aUser.features.foo()
may want want its parameter to be calleduser
notobj
.()
at the end. Thefeatures
registry was added for feature flags, to decide whether to expose some functionality or not. While it's currently used for UI-related model queries, it is meant for A/B-type testing, where bothTrue
andFalse
results are acceptable. Unfortunately, it possible for a template to accidentally use an{% if obj.features.foo %}
, skipping the()
, and this will always validate as True and also fail to show as a problem in tests. It should be possible to use a registry callable as a property, with no()
necessary.()
).RoleMixin
. As a result, when aRoleAccessProxy
is handed to a template, it will either be missing the registry entirely, or will be available raw, with all members accessible. Further, there is no option to cast to a dictionary, to send to the client as JSON.The text was updated successfully, but these errors were encountered: