Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Registry class needs enhancements #295

Open
3 of 4 tasks
jace opened this issue Apr 1, 2021 · 1 comment
Open
3 of 4 tasks

Registry class needs enhancements #295

jace opened this issue Apr 1, 2021 · 1 comment

Comments

@jace
Copy link
Member

jace commented Apr 1, 2021

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:

  1. 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.
  2. 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.
  3. The results of registry callables are not cached. Caching should be an option, and should use the property syntax (no ()).
  4. 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.
jace added a commit that referenced this issue Apr 3, 2021
@jace
Copy link
Member Author

jace commented Apr 3, 2021

The first three requirements are implemented in #297. Role access support is pending.

jace added a commit that referenced this issue May 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant