kjosib
commented
4 years ago Just a thought: the template stuff was originally conceived to be little more than string.format(...) with some smarts about the fact we're dealing in HTML (most of the time). It's grown a few bells and whistles over time. It's at about that level where I wonder if a bunch of simple hand-coded string manipulations and regex library calls remains the right approach. I certainly wouldn't want to add many more features this way.
Adding complexity and texture to the template language can and has lead to a more comfortable style of working, but to avoid a stinky knock-off of django and actually try to advance the art, I'd rather draw the semantic boundaries in a completely different manner. The basic idea:
- Don't only separate code from layout: the proper semantic boundary is more subtle than that.
- Nontrivial layout involves code: recognize and respect the fact.
- Don't embed a general-purpose language in a special-purpose tool: it undermines the purpose.
- Don't tempt developers to repeat themselves: capture genuinely-relevant and topical semantic ideas with syntax, and promote functional composition. A sample semantic is given in the
LoopTemplateclass. - Absolutely consider going beyond presentation and into something like control, to the extent that such control is difficult and error-prone on the Python side. An example would be stringing a navigable multi-page story together with session information: a template could read like an adventure game definition with browser interaction automatically stuck into the right places.
Anyway, this is going to simmer for a while.
Probably. The protocol service can rely on it for built-in/generic error/status messages. I'd feel more comfortable if the
ioliststuff wasn't so tightly tied to the idea of serving a HTTP response, though. For the moment it doesn't impact the API.