coaster
coaster copied to clipboard
Registry class needs enhancements
trafficstars
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:
- [x] All registry callables must accept an
objparameter. This is not ideal and should be configurable, asobjis only strictly necessary for forms. Thefeaturesregistry 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 calledusernotobj. - [x] All registry members require callable invocation, with
()at the end. Thefeaturesregistry 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 bothTrueandFalseresults 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. - [x] 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 aRoleAccessProxyis 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 first three requirements are implemented in #297. Role access support is pending.