On Fri, Mar 5, 2010 at 12:26 AM, Alex Gaynor <alex.gay...@gmail.com> wrote: > On Thu, Mar 4, 2010 at 3:41 AM, Russell Keith-Magee > <freakboy3...@gmail.com> wrote: >> On Thu, Mar 4, 2010 at 7:29 AM, Alex Gaynor <alex.gay...@gmail.com> wrote:
>>> Templates will be compiled by turning each template into a series of >>> functions, >>> one per block (note that the base template from which other templates >>> extend is >>> a single function, not one per block). >> ... >>> After an intermediate representation is created a compiler is invoked which >>> translates the IR into Python code. This handles the details of Django >>> template >>> scoping, spilling variables in the event of conflicts, and calling template >>> tag >>> functions. >> >> You don't ever say this explicitly, but I presume that the plan is to >> do this as an in-memory construction -- that is, the intermediate >> representation is handled in-memory, not as a python file on disk. >> You're proposing to writing a (2 pass?) compiler, not a code >> generator, right? >> > > My plan was an in-memory construction, but there's no reason once we > have the infrastructure in place that we couldn't generate templates > to disk. As for a compiler vs. a code generator, a compiler *is* a > code generator, so I'm not sure I see the distinction being made. Ok - sure - a compiler is a code generator. What I'm driving at is that you're not proposing that we move to a Cheetah-style model. The output of the compiler isn't something the end user should ever need to see, and won't ever see under normal circumstances. The compiled output isn't something the user will (under normal conditions) have the opportunity of modifying and editing, and they won't need to have makefiles or some similar construct to make sure their compiled templates are up to date. Django template use isn't going to devolve into "import mytemplate". >>> To provide an optimal solution we must know which variables a given template >>> tag needs, and which variables it can mutate. This can be accomplished by >>> attaching a new class attribute to ``Nodes`` and passing only those values >>> to >>> the class, (instead of the full context dictionary). Subsequently, we would >>> only need to mirror a few given values into the locals, and since these are >>> known names, we avoid degrading the local lookups into dictionaries. >>> Old-style >>> ``Nodes`` will continue to work, but in a less efficient manner. >> >> The term "less efficient" needs clarification here -- less efficient >> than a compiled node that has been specifically optimized for >> compilation, or less efficient than existing template rendering? It's >> completely understandable if a node doesn't render as fast as it's >> optimized and compiled counterparts, but I would consider it a failure >> if a compiled template resulted in a slowdown when compared to >> existing non-compiled rendering speed. >> > > less efficient than existing rendering, for that specific node. This > is because the Context dictionary would have to be rematerialized for > each and every old-style node in the template. That's what I expected; I just wanted to make sure we were on the same page. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
