Is your proposal related to a problem?
Pattern context modifiers are super-useful but they don't live alongside the template. You can potentially have a pattern_contexts.py in any app at all in your django project, and this can make it very tricky to figure out what context modifiers are applying to a particular pattern.
In addition, I might want to apply a pattern context modifier to only some templates, but currently you can apply it to either one or all tempaltes.
Describe the solution you'd like
In keeping with the recently popular idea of "locality of behaviour", I think that the YAML definition itself should include what modifiers you want to apply to it.
I'm proposing something like this in the pattern_contexts module:
# pattern_contexts.py module, inside a django app with an app label of "myapp"
# Note the 'scope' kwarg - the default would be "global" which is the current behaviour. "local" means only use it if configured to in the pattern yaml.
@register_context_modifier(scope="local")
def add_user_to_context(context: Context, request: HttpRequest) -> None:
context["user"] = User.objects.get(email="someuser@example.com")
And then in the pattern's YAML you could include what modifiers should be applied:
name: Badge
modifiers:
include:
- "myapp:add_user_to_context"
context:
color: blue
The register_context_modifier can introspect the modifier name ("add_user_to_context") from the function name, or it could be set via a name kwarg in register_context_modifier.
It'd also be nice to be able to explicitly turn off global modifiers, but I'm not as sure about that one.
Maybe that'd look something like:
name: Badge
modifiers:
include:
- "myapp:add_user_to_context"
exclude:
- "*"
context:
color: blue
Again, not so sure about that idea. I do like the idea of being able to say "for this pattern, I really don't want any external influences", but I'm not sure on the syntax.
Finally, I'd like to add some additional output on the pattern library "Template config" tab that lets you see which context modifiers will be applied to this context. This would be very useful for troubleshooting.
Describe alternatives you've considered
Custom yaml tags
There is a PR open here: #260
This PR looks like a pretty good implementation, but there are a couple of things I don't like about this solution:
- It's YAML- and pyyaml- specific. A pattern context is just a dictionary - there's no particular reason django-pattern-library needs to use yaml as a config format. I like that the context modifier system is agnostic to the choice of context configuration format.
- There's no namespacing of the yaml tags. That might be something that could be solved in the implementation, but I think it can get just as confusing if you have two apps that both have pattern libraries and both have pattern_contexts and both implement the same yaml tag - which one will actually get used?
- A context modifier has access to the overall context and the request object, which can be very useful.
Is your proposal related to a problem?
Pattern context modifiers are super-useful but they don't live alongside the template. You can potentially have a pattern_contexts.py in any app at all in your django project, and this can make it very tricky to figure out what context modifiers are applying to a particular pattern.
In addition, I might want to apply a pattern context modifier to only some templates, but currently you can apply it to either one or all tempaltes.
Describe the solution you'd like
In keeping with the recently popular idea of "locality of behaviour", I think that the YAML definition itself should include what modifiers you want to apply to it.
I'm proposing something like this in the pattern_contexts module:
And then in the pattern's YAML you could include what modifiers should be applied:
The register_context_modifier can introspect the modifier name ("add_user_to_context") from the function name, or it could be set via a
namekwarg in register_context_modifier.It'd also be nice to be able to explicitly turn off global modifiers, but I'm not as sure about that one.
Maybe that'd look something like:
Again, not so sure about that idea. I do like the idea of being able to say "for this pattern, I really don't want any external influences", but I'm not sure on the syntax.
Finally, I'd like to add some additional output on the pattern library "Template config" tab that lets you see which context modifiers will be applied to this context. This would be very useful for troubleshooting.
Describe alternatives you've considered
Custom yaml tags
There is a PR open here: #260
This PR looks like a pretty good implementation, but there are a couple of things I don't like about this solution: