On Tue, 2006-08-01 at 22:53 -0700, Gary Wilson wrote: > I never really liked how the templating system leaves all those > newlines. This middleware is cool, but it would really be nice if the > templating system could collapse the lines that only contain one or > more evaluating-to-nothing template tags. > > Thoughts on a possible implementation: > > What if an endofline token were added. Lexer.tokenize() creates the > tokens and Parser.parse() creates the nodelist like normal. Each node > in the nodelist is rendered, except for endofline nodes. Pass through > nodelist again, removing whitespace-strings and empty-strings if those > whitespace-strings and empty-strings are all that exist between two > endofline nodes. The endofline nodes following removed > whitespace-strings or empty-strings are also removed, while all other > endifline nodes get rendered to a newline. Join and return rendered > nodelist like normal. > > Would this work? Is there a better way?
The big question with this sort of thing is always going to be speed. Rendering templates is pretty fast at the moment, but it wants to be, too. That being said, I haven't implemented or profiled your approach, so I have no idea of its real impact, but you are introducing another pass over the source text chunks (chunks == the results of an re.split() call). I've been experimenting with a somewhat funky reg-exp change inside the template parser that would have the same effect as yours. I'm still optimising it (I *knew* there was a reason that part of Friedl's book existed) and profiling the results, but it looks possible. Essentially, this would have the same effect you are after: a blank line that results from just template directives is removed entirely. Any spaces or other stuff on the line are left alone, though, so it's a very selective reaper. My motivation here was having to debug an email generation template yesterday that was like a train wreck with all the template tags jammed together to avoid spurious blank lines. It's going to be a few more days before I can work on this seriously, I suspect (there are two more urgent Django things I need to finish first, for a start), so you might like to experiment along those lines too, if you're keen. I'm not sure I like my solution a lot, either, since it makes things a little more opaque in the code; still having debates with myself about that. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
