I was using both BeforeRender and base-class view methods in an
application, then I read about Mustache templates, and while I decided
not to use Mustache, I liked the idea of having as little magic and
complications in my templates as possible. So I reconfigured my base
view into a dict subclass, and now I have the view methods return
'self'. This allows the base view constructor to set variables for the
site template, and the methods it calls can do so too. The view
methods can then set their variables as they calculate them (e.g.,
``self["foo"] = "Foo"``), rather than having to assemble one big dict
at the end and repeat variables (``{"foo": foo}``). It's kind of like
reviving Pylons' ``c`` variable but without the magic. Anyway, I'm
satisfied with this approach, and using it in more complex
applications. (In small applications that don't have any site-template
variables, I don't bother.)
In further simplifying my templates, I'm still using Mako's template
inheritance and template functions and Python expressions, but
anything I can precaculate in the view, especially anything complex
that might raise an exception, I calculate before the template. That's
partly because it's harder to debug exceptions in templates, because
only sometimes do you get a full traceback with the actual line of the
real error.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
