Hello Gregor,

Thanks for taking a look.  My rationale is, "Why change all the
editors in the world for something that can be simplified with an
easier syntax?"

All of the previous code using the curly-modulo syntax -- {%%} would
still be functional for as long as the core developers chose to
support it.

The only possible breakage (as i understand it at least) would be if
the namespace issue I previously mentioned. That would mean people
have been naming their variables or tables things like "block","if",
etc, which would seem to be pretty poor programming practice in terms
of readability.  Finally, the triple bracket solution would avoid even
that issue if creating a few keywords were to be out of the question.
As to your last point, I don't know how many programming languages
have implemented their own versions of the DTL, but if this would be
an improvement, as I feel it would, then it seems all such
implementations would benefit as well.

Cordially,
Daniel

On May 26, 5:32 pm, Gregor Müllegger <[email protected]> wrote:
> Hi Daniel,
>
> I think your suggestion might make sense for some people using
> autoclosing brackets etc. But having better support for writing
> templatetags is just an issue with a text editor which might be
> configurable and easy to write a plugin or using a snippet completion
> to make life easier for you typing things.
>
> So in my opinion its unlikely that your proposal will be intergrated
> into django because it breaks backwards compatibility without having
> any functional improvement. You would need to update all existing
> django templates and it also breaks compatibility with implementations
> of the DTL in other programming languages.
>
> Gregor
>
> disclaimer: I'm not a core-developer and are not responsible for any
> design decisions.
>
> On 26 Mai, 20:24, Daniel <[email protected]> wrote:
>
>
>
> > Hi, I was just referred here with a suggestion I posted on the django
> > ticket tracker. I've been studying the way we do template tags, and
> > had a suggestion for how to revise them to make them a bit easier. I
> > was thinking that out of the tags, I like the variable syntax the best
> > -- {{ variable.attribute }}. I realize that if we were to use the
> > double curly brackets on all of the tags, they might conflict with the
> > namespace, but it seems like having "block", "if", "elsif", "else",
> > "for", and "extends" and their respective 'end'ings as keywords would
> > not be burdensome. It's really unpleasant typing {%%} and left arrow
> > twice, space, the item name, and space for every tag and for its
> > closing tag.
>
> > An alternative that wouldn't affect the namespace but would still be
> > more convenient for both plain typing and possibly for code completion
> > (I don't know why eclipse pydev doesn't close these tags) would be
> > triple brackets --  {{{ block head }}}.
>
> > Thanks for your time,
> > -Dan
>
> > p.s. not sure if the code will show up appropriately in the above, but
> > hopefully you get the picture.  Also, I'm on Windows and/or Linux...
>
> > Here's the initial reply:
> > -----------------------------------------------------------------
> > Change History
> > 05/26/10 14:01:25 changed by adamnelson
> > status changed from new to closed.
> > needs_better_patch changed.
> > resolution set to invalid.
> > needs_tests changed.
> > needs_docs changed.
>
> > I think it's a reasonable request but this would require a rigorous
> > discussion on django developers newsgroup before even having a ticket
> > and would be more like a 1.4 thing:
>
> >http://groups.google.com/group/django-developers
>
> > You may want to try TextMate Django bundles to make this easier on a
> > Mac - I don't have any other suggestions though.
>
> > Cheers.

-- 
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?hl=en.

Reply via email to