coaster
coaster copied to clipboard
Registry class needs enhancements
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
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
. - [x] All registry members require callable invocation, with
()
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. - [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 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 first three requirements are implemented in #297. Role access support is pending.