Bryanv/3962 server templates #4176
Conversation
|
@birdsarah Do you think you could add some minimal template and styling around one of the apps (maybe |
|
@bokeh/dev @havocp I feel like there might be some conceptual fuzziness between handlers, applications, and commands. Mostly this its just about who is responsible for what, and how best to generally handle combinations that "don't make sense". We seem to be getting lots of cases like this where it makes sense for "at most one handler to do XYZ" maybe there is some pattern that would help encapsulate this better. |
|
E.g., maybe we can find a declarative way to tag handler classes by the optional features they might provide. This could help both with checking the "at most one..." cases but also help with warnings or alternate code paths (e.g a |
|
each handler modifies the document, right? they are allowed to overwrite each other. I think the conceptually-pure approach here would be that if two handlers both set doc.template, the second one just wins. But making it an error is perhaps more useful/practical, if we believe (and this is probably true) that two templates represents a mistake. |
| @@ -0,0 +1,2 @@ | |||
|
|
|||
| ldsfjlaskgjgldjfg | |||
There was a problem hiding this comment.
Was this intended to be committed?
|
Sure, that approach occurred to me to, it's certainly consistent with e.g., general python namespace behavior. But even if we go that route, practically speaking I think we need to at least warn if it happens. |
| HERE IS SOME CUSTOM STUFF | ||
| </div> | ||
| {{ plot_div|indent(8) }} | ||
| {{ plot_script|indent(8) }} |
There was a problem hiding this comment.
to me this is too obscure, I'd love to see it simplified down to {{bokeh_head}}, {{document}}, and {{title}} perhaps (or other more obviously-meaningful things). I believe it's possible to do that without breaking the ability to also do the above more detailed breakdown. But it could be its own PR for sure.
There was a problem hiding this comment.
other than clarity, making this less granular would mean fewer apps break if the implementation details ever change...
There was a problem hiding this comment.
Yes sorry I should have specified, I am definitely wanting to spread things out over a few independent PRs. This one make a minimal change to add a pretty important capability, do intend to refine it more.
|
A kind of weird thing is that people can change curdoc().template in a callback, which would only ever do anything if the same session was reloaded, so it would probably be pointless. Not sure we could/should bother to do anything about it. |
| if not isinstance(template, jinja2.Template): | ||
| raise ValueError("Document templates must be Jinja2 Templates") | ||
| self._template = template | ||
| # TODO (bev) template change eventing? |
There was a problem hiding this comment.
I can't think of where change notification would be practically useful right now, fwiw
|
should |
|
Well so that's my question, is a template a property of the |
|
Yes |
|
Either way can probably be made to work... if the static resources are on application and not doc, maybe it makes sense to keep it with those. Document could try to be more only the thing that's modified on the fly and synced over the websocket, Application would provide the HTML "container" around the document ? |
For sure, tho being able to set it programmatically at the end of an app script seems useful. I could imagine ways to warn about this, though... Setting an |
|
@bokeh/dev I think there may eventually be tweaks to make to the implementation, but I think the user-facing interface reasonable as-is. I've simplified some things as described above (i.e., handlers just update templates in order without error) I'd like to merge this PR as it is and make incremental improvements. |
|
@bokeh/dev I will plan to merge this tomorrow sometime absent objection. |
bokeh serve#3962This PR adds initial support for overriding the default
FILEtemplate for Bokeh apps with a custom user-specified template.