Rethinking TurboStan Namespaces

Filed under: turbostan 

I'm seriously entertaining the idea of deprecating the "vars" prefix attached to variables passed to TurboStan templates. There needs to be some sort of prefix to avoid namespace messes, but I'm thinking a bit more separation is in order: I'm considering passing the model as the "model" object and variables passed from the controller as the "view" object, so you'd see stuff like:

h1 [ view.title ],
div ( id = 'content' ) [
    view.content
],
ul ( id = 'articles', render = render.sequence, data = model.Article.data.articles   [
    li ( pattern = 'item', render = model.Article.render.link )
]

I've debated whether to use "view" or "controller" to group variables and methods passed from the controller, but "controller" is awful long and "view" seems a reasonable alternative (especially since TurboGears will be replacing @expose with @view soon).

My main concern is that this would subtly move TurboStan further away from TurboGears in yet another way. Because TurboStan knows nothing about the model, it would be up to the programmer to properly layout the namespaces in the returned dictionary:

return dict = (
    model = model,
    view = dict (
       title = 'A history of the world',
       content = 'Hello, world'
    )
)

Alternatively, I could rely on the fact that TurboGears puts the model in model.py and import that directly in TurboStan. While helping make things a bit more transparent, it also ties TurboStan more closely to TurboGears, which is a downside for people looking to use it outside of TG.

To date, I'm unsure how I feel about this.



0 comments Leave a comment