Yes please! Nice catch and followup :)
Cheers,
Markus
On Mon, May 4, 2020, at 4:08 PM, Jon Dufresne wrote:
> Hi,
>
> I'd like to raise this topic for renewed discussion. I think it is time
> to begin deprecating the obsolete template tags. So +1 for removal.
>
> I had all but forgotten about
Agreed. We should deprecate both.
(I could even put a recommended command in the release notes).
>
I don't think it's a good idea. You can attach "unofficial" script in the
ticket, but release notes are not a proper place, IMO. It may not behave
properly in block comments etc. Don't get me
+1 for removal. 5 years have nearly passed since that discussion with the
docs saying "The ifequal and ifnotequal tags will be deprecated in a future
release." so I think it's worth actioning.
(I could even put a recommended command in the release notes).
>
I like this idea. It would also be
Hi,
I'd like to raise this topic for renewed discussion. I think it is time to
begin deprecating the obsolete template tags. So +1 for removal.
I had all but forgotten about the {% ifequal %} template tag and then
eventually stumbled across it doing unrelated work. Upon rediscovering it
as a
Hi All,
I really like the "don't use this on new code, but there's no rush in
replacing it" category. I think that's really important to have that in a
project that's this old. I think it would be great to minimize the amount
required changes that need to be done.
Thanks,
Collin
--
You
On Fri, Aug 7, 2015 at 3:06 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> > On 7 août 2015, at 05:43, Curtis Maloney
> wrote:
> >
> > I'd probably go with updating the documentation to say they're legacy
> > tags, you're better off using {% if %}
I think Tim's suggestion of releasing the tag as a separate library which
can be included in builtins answers Karen's concerns about updating 3rd
party templates. I admit that is a case I had not considered.
Marc
On 7 Aug 2015 15:31, "Tim Graham" wrote:
> I put together a
I put together a pull request to see how much code we are talking about:
https://github.com/django/django/pull/5114
It's 275 lines of code (mostly tests). I don't mind the outcome of the
decision either way, but as it's been 5 years since the release of 1.2 and
the "smart if" tag, I'm not sure
Django 1.9 has the option to add templates tags to the builtins using the
TEMPLATES setting, so it wouldn't be difficult to publish a third-party app
with the legacy tags and document how to use it in legacy projects that
have difficulty updating:
OPTIONS={
'builtins': ['ifequal.tags'],
}
> On 7 août 2015, at 05:43, Curtis Maloney wrote:
>
> I'd probably go with updating the documentation to say they're legacy
> tags, you're better off using {% if %} now, and warn they may be
> removed in a later release.
This is my inclination as well. Then we can
I'd probably go with updating the documentation to say they're legacy
tags, you're better off using {% if %} now, and warn they may be
removed in a later release.
This way (a) people are warned off it, and (b) we're confusing people
who find it and want to check what it does [even though it's
Fair enough, I don't necessarily disagree with you. Would removing the
documentation for ifequal be OK? At least that would prevent new projects
from using it or being confused about multiple ways to compare values.
On Friday, 7 August 2015 12:49:37 UTC+10, Karen Tracey wrote:
>
> We certainly
We certainly weren't discussing removing without deprecating, were we? I'm
saying removing isn't worth the hassle to users, period. My opinion from
working on a fair number of inherited sites, plus sites where I don't get
to choose who contributes code I'm responsible for maintaining. I've
Can we just push the ifequal type tags through regular deprecation? As
mentioned, the cost of maintaining the tags is extremely low. Remove the
ifequal tags from the docs, document their deprecation, and remove in
Django 2.0.
On Friday, 7 August 2015 11:56:29 UTC+10, Curtis Maloney wrote:
>
>
Given the [currently] low burden, I agree with a more gradual
deprecation... document against their use to help encourage people to
move away from them, then we're in a better position to more
painlessly remove them in the future.
--
Curtis
On 7 August 2015 at 11:43, Karen Tracey
Believe me I understand what technical debt is. In my opinion the cost of
this debt in Django is not sufficient to warrant the cost to users of
Django to remove it. Find and fix (or figure out if it's necessary to fix)
all templates (some of which may be coming from 3rd party packages) used
in a
Let me open by saying I am in no way averse to the removal of these
two tags... and this reminds me I need to also re-work my "remove the
'x as y' argument syntax" patch again...
On 7 August 2015 at 07:08, Marc Tamlyn wrote:
> However, as with all technical debt, it has a
ifequal is technical debt in Django. It's a legacy way of doing things
which we would not add now. Sure, we don't have to remove it, it isn't
blocking us from doing anything else and it isn't broken, and it doesn't
need much maintenance.
However, as with all technical debt, it has a cost. It's
On Thu, Aug 6, 2015 at 12:15 PM, Daniel Greenfeld wrote:
> No modern project uses ifequal. No one recommends it. I argue it is taking
> up valuable bytes in the project. Let's remove it.
>
I maintain (did not write) a project written last year that has ifequal and
ifnotequal.
Also +1 for its removal. And ifnotequal, too, since nobody seems to have
mentioned this yet.
I would imagine a simple regex find-and-replace very much enough to fix
most problems this causes. And if someone *really* want those tags, it is
also pretty trivial to just pull them into a
I commented on the ticket - it's been redundant since Django 1.2 when the
smart if was introduced. +1 to deprecating it.
On 6 August 2015 at 17:15, Daniel Greenfeld wrote:
> No modern project uses ifequal. No one recommends it. I argue it is taking
> up valuable bytes in the
21 matches
Mail list logo