[7084] extends headaches

[David Larlet]

Hello,

I'd just updated my local version of django and it raises errors due
to 7084 changeset (extends should be the first tag). I put all my
extends tags above all my load tags in every templates and I realize
that it raises errors for comment tags too... I used to keep svn infos
at the top of every file and now I need to put extends tag at the top
of every templates, a bit annoying. I understand that it avoids some
errors but I think that we could make an exception for comment tags
and maybe load tags too. Any thoughts?

By the way, it could be interesting to list that as a new backward
incompatible change?

Best,
David

[Collin Grady]

David Larlet said the following:

> I'd just updated my local version of django and it raises errors due
> to 7084 changeset (extends should be the first tag). I put all my
> extends tags above all my load tags in every templates and I realize
> that it raises errors for comment tags too... I used to keep svn infos
> at the top of every file and now I need to put extends tag at the top
> of every templates, a bit annoying. I understand that it avoids some
> errors but I think that we could make an exception for comment tags
> and maybe load tags too. Any thoughts?

The extends tag was always supposed to be the first tag in a file - this
has been documented for many versions now. If it happened to work
before, *that* was the bug, and so there's no change in expected
behavior, merely a bugfix that let you break it before :)

As such, I don't see that this is a backwards incompatible change, myself.

--
Collin Grady

All celebrity voices impersonated.

[Malcolm Tredinnick]

On Tue, 2008-02-05 at 16:14 +0100, David Larlet wrote:
> Hello,
>
> I'd just updated my local version of django and it raises errors due
> to 7084 changeset (extends should be the first tag). I put all my
> extends tags above all my load tags in every templates and I realize
> that it raises errors for comment tags too... I used to keep svn infos
> at the top of every file and now I need to put extends tag at the top
> of every templates, a bit annoying. I understand that it avoids some
> errors but I think that we could make an exception for comment tags
> and maybe load tags too. Any thoughts?

Aah .. comment tags. Forgot about those. I'll fix it.

> By the way, it could be interesting to list that as a new backward
> incompatible change?

No, it's not meant to be backwards incompatible for correct code.; it's
just raising more visible errors. Not having the extends tag first (for
some definition of "first") was an error in any case and usually didn't
work, but the failure was often disguised.

Regards,
Malcolm

--
The sooner you fall behind, the more time you'll have to catch up.
http://www.pointy-stick.com/blog/

[David Larlet]

Le 5 févr. 08 à 22:05, Malcolm Tredinnick a écrit :

>
>
> On Tue, 2008-02-05 at 16:14 +0100, David Larlet wrote:
>> Hello,
>>
>> I'd just updated my local version of django and it raises errors due
>> to 7084 changeset (extends should be the first tag). I put all my
>> extends tags above all my load tags in every templates and I realize
>> that it raises errors for comment tags too... I used to keep svn
>> infos
>> at the top of every file and now I need to put extends tag at the top
>> of every templates, a bit annoying. I understand that it avoids some
>> errors but I think that we could make an exception for comment tags
>> and maybe load tags too. Any thoughts?
>
> Aah .. comment tags. Forgot about those. I'll fix it.

Ok thanks.

>
>
>> By the way, it could be interesting to list that as a new backward
>> incompatible change?
>
> No, it's not meant to be backwards incompatible for correct code.;
> it's
> just raising more visible errors. Not having the extends tag first
> (for
> some definition of "first") was an error in any case and usually
> didn't
> work, but the failure was often disguised.

I agree with you that it's not a backward incompatible change, but
imagine you've missed that point and you decide to update your copy of
django, it will result in a broken site. I think that it could be
interesting to communicate on that point.

Best,
David

[Malcolm Tredinnick]

It already results in a broken site, we're now just being a lot clearer
about that.

Still, it's a wiki, feel free to update it if you like.

Regards,
Malcolm

--
I don't have a solution, but I admire your problem.
http://www.pointy-stick.com/blog/

[SmileyChris]

On Feb 6, 9:43 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

> It already results in a broken site, we're now just being a lot clearer
> about that.

Actually, it only resulted previously in a broken site if the extended
template was being used in more than one depth of inheritance.

>
> Still, it's a wiki, feel free to update it if you like.

Yea, go ahead and update it David, I think it's fair enough.

[David Larlet]

Le 6 févr. 08 à 21:01, SmileyChris a écrit :

I'd tried to use my best english but corrections are welcome :)
http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Raiseerrorsifextendsisnotthefirsttagofatemplate

Best,
David

[J. Cliff Dyer]

I made a couple of minor grammatical changes for clarity, but your
english was pretty good, David.

Cheers,
Cliff

[David Larlet]

Thanks, I try to do my best and five mistakes in the same sentence is
not that bad ;)

Cheers,
David

Le 7 févr. 08 à 15:31, J. Cliff Dyer a écrit :

>
> I made a couple of minor grammatical changes for clarity, but your
> english was pretty good, David.
>
> Cheers,
> Cliff
>
> On Thu, 2008-02-07 at 15:06 +0100, David Larlet wrote:
>>

>> Le 6 f�vr. 08 � 21:01, SmileyChris a �crit :

[AmanKow]

I've reopened http://code.djangoproject.com/ticket/5124.
'contains_nontext' must be an instance attribute, not a class
attribute in 'NodeList'. There is a patch attached.

Wayne

[AmanKow]

BTW, do I understand this correctly...
{# comment #} is alright, but {% comment %} ... {% endcomment %} is
not? I don't see anything in the code that would allow block
comments. Would be nice if it did...

Wayne

[AmanKow]

This could be implemented easily by having the comment() function in
defauttags.py return an empty TextNode and doing away with the
CommentNode class entirely.

Thoughts?
Wayne

[AmanKow]

On Feb 7, 2:14 pm, AmanKow <wwer...@si.rr.com> wrote:
> I've reopenedhttp://code.djangoproject.com/ticket/5124.

> 'contains_nontext' must be an instance attribute, not a class
> attribute in 'NodeList'. There is a patch attached.

Arrggh... my humble apologies... been following the template code,
just got back from a three day crash business trip, and wasn't
thinking clearly when I started looking at the recent changes.
Sometimes my poor old brain still wanders down old c++ pathways,
especially when I'm dog tired!

Please ignore the previous message re instance vs class attribute!