On Fri, 2006-08-04 at 14:01 -0500, Tom Tobin wrote:
> On 8/4/06, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
> >
> > In Rails, template tags can have an extra hyphen at the end to denote
> > the fact that they should consume the newline right after the tag. So:
> >
> > {% some_tag %}
> >
> > Would look like this:
> >
> > {% some_tag -%}
>
> I can't help but feel that this syntax is ugly and, furthermore, easy
> to miss while scanning through a template. I wouldn't mind having to
> set something once in my root-level template (e.g., {% chomp %}{%
> endchomp %}) if it was picked up by child templates inheriting from
> it.
Not targeted at this particular response specifically (although it also
applies here), but more to head off a bunch of "here's a syntax change
we could make" replies...
Slightly tricky syntax changes was one of the problems with the original
ticket that was marked as "wontfix". It's complicating things too much
to add all this extra syntax. Nobody has come up with a good reason not
to consume lines that only consist of empty template tags and leading
whitespace, so we should just do the Right Thing always. Not
configurable, not optional, just do it. (There may be a reason; Anybody
who has concerns should feel free to sing out.)
General philosophy (eventually something like this will get written up
and placed in Django's documentation, along with a few other similar
points): It's very easy to go overboard when considering changes and try
to make everything configurable in order to please the mythical
"everybody". That has the effect of increasing the maintenance load (now
there are multiple code paths to maintain), increase the learning curve
(I'm just starting out with Django; why are there 200 configuration
options? Which ones do I care about?), increase the documentation load
and length (200 configuration options, again, that have to be kept up to
date) and increase the amount of knowledge a template designer needs (in
this case; remember that the template language is an *extra* thing a web
page developer needs to learn on top of all their other skills). Now
you've managed to make life harder for four groups of people with one
change designed to make things easier. Possibly not the intended
win-loss ratio.
For the sort of change Gary proposed, which is essentially identical to
what I and no doubt others had arrived at as well, there is no
meaningful semantic or syntactic difference for almost all cases. There
is a way to emulate the old (current) behaviour, so no functionality is
lost. PLus the new behaviour feels a bit more intuitive to many people,
it appears.
Back to the original problem:
My initial solution that I talked about the other day didn't work in a
few cases (ten minute hacks do that sometimes). I'll get back to this
today and see what we can come up with that is non-invasive, fast and
correct.
Best wishes,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
