Proposal: Shorter comment tag
scum
The current convention is a bit bulky for my taste.
{% comment %}
{% if 1 %}{% endif %}
{% endcomment %}
could be simplified to...
{! {% if 1 %}{% endif %} !}
or
{% comment %} Short comment about following code {% endcomment %}
could be...
{! Short comment about following code !}
What do you guys think?
Adrian Holovaty
> Could the comment tag be simplified to something like {! !} or {# #}.
We've already got two different types of tags -- {% %} and {{ }} --
and introducing a third would be too complex for my tastes.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
Russell Keith-Magee
On 1/11/06, scum <scumi...@gmail.com> wrote:
> Could the comment tag be simplified to something like {! !} or {# #}.
We've already got two different types of tags -- {% %} and {{ }} --
and introducing a third would be too complex for my tastes.
Adrian
Not wanting to disagree with the glorious leader :-), but I have to say I like the idea.
First off, it's not that hard to explain in documentation:
- a { } block is a template operation
- Inside a {} block, you can use
{} means a substit
Russell Keith-Magee
Crap. Lets try this again without tabbing onto the send button.
On 1/11/06, scum <scumi...@gmail.com> wrote:
> Could the comment tag be simplified to something like {! !} or {# #}.
We've already got two different types of tags -- {% %} and {{ }} --
and introducing a third would be too complex for my tastes.
Second, the {# #} choice suggested has nice symmetries with Python (in that it uses the # character).
Third, the "three types of tag" thing isn't difficult to explain in documentation:
- {} for a literal or filtered substitution
- %% for some logic
- ## for a comment
My 2 c. But then, thats AU cents, so it's only 1.3 c US...
Russ Magee %-)
Amit Upadhyay
Crap. Lets try this again without tabbing onto the send button.
On 1/12/06, Adrian Holovaty < holo...@gmail.com> wrote:
On 1/11/06, scum <scumi...@gmail.com> wrote:
> Could the comment tag be simplified to something like {! !} or {# #}.
We've already got two different types of tags -- {% %} and {{ }} --
and introducing a third would be too complex for my tastes.
Not wanting to disagree with the glorious leader :-), but I have to say I like the idea.
First off; comments should always be encouraged, and the easiest way to make something
+1 to that.
I just did a project in django and the templates were managed by a designer and he would make many mistakes, like not copying {% if %} {% endif %} around {{ variable }} when moving the variable around. Also its not very clear when modifying templates what all variables are available, and I had to regularly go back to view code to reconfirm the variable names etc. Comments are extreamly helpful, and any work to make them easy or encourage them is well worth it, and making a special {! !} would make it all the more obvious in the documentation, after all the first thing we read about templates is the template tags.
Another request: if debug is on, and if the url contains ?dumpTemplateContext, and client IP in settings.trusted_hosts [and blah blah blah depending on how paranoid you are], render_to_response, and family, ignores the actual template, and instead dumpts the context variable passed, and detailed instuctions about their type, and some comment on how to loop if the variable is list like and so on. This is meant to be used by the designers who would be creating template, so it can contain a link to tutorial, or dump the tutorial and faq and everything, anything to make the job of designer easier.
Amit Upadhyay
Blog: http://www.rootshell.be/~upadhyay
+91-9867-359-701
Simon Willison
On 12 Jan 2006, at 07:23, Amit Upadhyay wrote:
> Another request: if debug is on, and if the url contains ?
> dumpTemplateContext, and client IP in settings.trusted_hosts [and
> blah blah blah depending on how paranoid you are],
> render_to_response, and family, ignores the actual template, and
> instead dumpts the context variable passed, and detailed
> instuctions about their type, and some comment on how to loop if
> the variable is list like and so on. This is meant to be used by
> the designers who would be creating template, so it can contain a
> link to tutorial, or dump the tutorial and faq and everything,
> anything to make the job of designer easier.
This could almost be done right now using middleware, without any
changes to Django proper. If the middleware proved useful enough it
could then be rolled in to Django proper.
The thing holding back a middleware implementation is the decoupling
of response objects and the template system. The middleware would
have to intercept the HttpResponse object returned by the view
function and extract the template and context from it, but by that
point the template has been rendered in to a string.
This isn't the only case where being able to introspect in to the
template and context used during a request would be useful. The other
obvious use case is writing unit tests - a Django application test
harness would benefit greatly from the ability to run a view function
with certain parameters and then inspect the template, context and
HttpResponse object produced by that view.
I'm certainly not suggesting we couple HttpResponse to the template
library, but is there some kind of middle ground? I know we use crazy
stack tracing hacks already for the fancy error pages but that seems
like a bit of a hack. Maybe we could do something with PyDispatcher -
maybe t.render(c) could fire a "template A has been rendered with
context B" event which other bits of code (related to dynamic view
documentation and/or unit testing) could listen out for.
Is there a better way of solving this problem?
Cheers,
Simon
Wilson
> clear when modifying templates what all variables are available, and I had
> to regularly go back to view code to reconfirm the variable names etc.
You may find the built-in view/model docs (hit "/admin/doc/" with admin
installed) very helpful.
scum
this piece of middleware for your projects. It's my first attempt at
middleware so the code might seem a bit immature for you advanced
djangoers out there. I opted to use the {# #} syntax, but that can
easily be changed in the regular expressions below.
#################################################
### The Middleware
#################################################
import re
regx_extractComments = re.compile('(\{\#.*?\#\})', re.DOTALL)
class NewCommentMiddleware:
def process_response(self, request, response):
if response.has_header and response.headers.get("Content-Type",
"")[0:9] == "text/html":
response.content = regx_extractComments.sub( "", response.content)
return response
###################################################
## For the TextMate Django Bundle. Add following to `HTML (Django)`
###################################################
{ name = 'comment.block.django.template';
begin = '{#';
end = '#}';
},
slumtrimpet
Russell makes some very good points. Comments should always be
encouraged in code and should be easy to insert in code for debugging
purposes. The current {% comment %} blocks are a bit of a pain to
write for both of these purposes.