Url tag and context variables (Re: #7917)
5 views
Skip to first unread message
Ulrich Petri
Mar 19, 2009, 10:30:51 PM3/19/09
to Django developers
Hi,
since #9666 (SSI-tag variable resolving) got accepted by Jacob lately
I would like to restart discussion about the same functionality for
the url template tag (as was already proposed in #7917).
Pro arguments:
- The url tag is one of the few remaining tags that doesn't accept a
variable as it's "main" argument and is therefore inconsistent
behaviour.
- Allowing variables would enable the use in inclusion tags (e.g. a
pagination inclusion tag which takes a view name as argument - leading
to cleaner urls without get parameters with is beneficial for caching
etc.) .
- Generally reducing DRY in templates with similar content but
different links.
Contra arguments:
- Possible name clashes between views and template variables.
- May possibly lead to difficult to track down behaviour.
Personally I think the benefits outweigh the risks especially if the
changes are phased in over a period of time.
For example:
1.2: Add the try-resolving-first-then-fall-back-to-literal behaviour.
1.3: Deprecate non-quoted literal view names and issue a warning if
they are used
1.4: Switch to "normal" variable/filter parsing as found in many other
tags.
What do you think?
Ulrich
P.S.: If needed I can provide a patch for the proposed behaviour. It
would be largely similar to the updated patch of #9666.
since #9666 (SSI-tag variable resolving) got accepted by Jacob lately
I would like to restart discussion about the same functionality for
the url template tag (as was already proposed in #7917).
Pro arguments:
- The url tag is one of the few remaining tags that doesn't accept a
variable as it's "main" argument and is therefore inconsistent
behaviour.
- Allowing variables would enable the use in inclusion tags (e.g. a
pagination inclusion tag which takes a view name as argument - leading
to cleaner urls without get parameters with is beneficial for caching
etc.) .
- Generally reducing DRY in templates with similar content but
different links.
Contra arguments:
- Possible name clashes between views and template variables.
- May possibly lead to difficult to track down behaviour.
Personally I think the benefits outweigh the risks especially if the
changes are phased in over a period of time.
For example:
1.2: Add the try-resolving-first-then-fall-back-to-literal behaviour.
1.3: Deprecate non-quoted literal view names and issue a warning if
they are used
1.4: Switch to "normal" variable/filter parsing as found in many other
tags.
What do you think?
Ulrich
P.S.: If needed I can provide a patch for the proposed behaviour. It
would be largely similar to the updated patch of #9666.
Malcolm Tredinnick
Mar 19, 2009, 10:48:43 PM3/19/09
to django-d...@googlegroups.com
On Thu, 2009-03-19 at 19:30 -0700, Ulrich Petri wrote:
> Hi,
>
> since #9666 (SSI-tag variable resolving) got accepted by Jacob lately
> I would like to restart discussion about the same functionality for
> the url template tag (as was already proposed in #7917).
>
> Pro arguments:
> - The url tag is one of the few remaining tags that doesn't accept a
> variable as it's "main" argument and is therefore inconsistent
> behaviour.
> - Allowing variables would enable the use in inclusion tags (e.g. a
> pagination inclusion tag which takes a view name as argument - leading
> to cleaner urls without get parameters with is beneficial for caching
> etc.) .
> - Generally reducing DRY in templates with similar content but
> different links.
>
> Contra arguments:
> - Possible name clashes between views and template variables.
> - May possibly lead to difficult to track down behaviour.
> Hi,
>
> since #9666 (SSI-tag variable resolving) got accepted by Jacob lately
> I would like to restart discussion about the same functionality for
> the url template tag (as was already proposed in #7917).
>
> Pro arguments:
> - The url tag is one of the few remaining tags that doesn't accept a
> variable as it's "main" argument and is therefore inconsistent
> behaviour.
> - Allowing variables would enable the use in inclusion tags (e.g. a
> pagination inclusion tag which takes a view name as argument - leading
> to cleaner urls without get parameters with is beneficial for caching
> etc.) .
> - Generally reducing DRY in templates with similar content but
> different links.
>
> Contra arguments:
> - Possible name clashes between views and template variables.
> - May possibly lead to difficult to track down behaviour.
I was one of the original people in favour of making this change, but
since it was decided not to go down that path (disappointingly, it
seems, mostly through apathy at the time), I think we shouldn't change
it now. the fact that it will either require a backwards-incompatible
syntax change or lead to ambiguity as to whether a view or string is
intended is a big enough negative to think it's not worth doing.
Particularly a you're proposing a system that changes the behaviour in
every single release for the next three releases.
Make no mistake, I would love to fix it properly, but I think the better
approach is to introduce a new tag and then deprecate the old one, where
the new tag handles strings consistently.
Certainly right now is not the time to do it. This needs a discussion,
but we also have a lot of 1.1 things needing discussion. Work on making
your patch perfect, but let's postpone the design discussion until 1.1
is out the door, when we have time to focus on things a bit more.
Regards,
Malcolm
Ulrich Petri
Mar 19, 2009, 11:06:24 PM3/19/09
to Django developers
On 20 Mrz., 03:48, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> I was one of the original people in favour of making this change, but
> since it was decided not to go down that path (disappointingly, it
> seems, mostly through apathy at the time), I think we shouldn't change
> it now. the fact that it will either require a backwards-incompatible
> syntax change or lead to ambiguity as to whether a view or string is
> intended is a big enough negative to think it's not worth doing.
> Particularly a you're proposing a system that changes the behaviour in
> every single release for the next three releases.
>
> Make no mistake, I would love to fix it properly, but I think the better
> approach is to introduce a new tag and then deprecate the old one, where
> the new tag handles strings consistently.
>
> Certainly right now is not the time to do it. This needs a discussion,
> but we also have a lot of 1.1 things needing discussion. Work on making
> your patch perfect, but let's postpone the design discussion until 1.1
> is out the door, when we have time to focus on things a bit more.
>
> Regards,
> Malcolm
Ok, thanks for the reply.
> since it was decided not to go down that path (disappointingly, it
> seems, mostly through apathy at the time), I think we shouldn't change
> it now. the fact that it will either require a backwards-incompatible
> syntax change or lead to ambiguity as to whether a view or string is
> intended is a big enough negative to think it's not worth doing.
> Particularly a you're proposing a system that changes the behaviour in
> every single release for the next three releases.
>
> Make no mistake, I would love to fix it properly, but I think the better
> approach is to introduce a new tag and then deprecate the old one, where
> the new tag handles strings consistently.
>
> Certainly right now is not the time to do it. This needs a discussion,
> but we also have a lot of 1.1 things needing discussion. Work on making
> your patch perfect, but let's postpone the design discussion until 1.1
> is out the door, when we have time to focus on things a bit more.
>
> Regards,
> Malcolm
I will think about it some more and bring it up again once 1.1 is "out
of the door".
Bye
Ulrich
Soviut
Apr 6, 2009, 11:31:46 AM4/6/09
to Django developers
I accidentally duplicated this ticket (http://code.djangoproject.com/
ticket/10745) but I provided a diff that applies the change. Should I
add this to ticket #7917?
On Mar 19, 10:48 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
>
> > Pro arguments:
> > - Theurltagis one of the few remaining tags that doesn't accept a
> the newtaghandles strings consistently.
ticket/10745) but I provided a diff that applies the change. Should I
add this to ticket #7917?
On Mar 19, 10:48 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Thu, 2009-03-19 at 19:30 -0700, Ulrich Petri wrote:
> > Hi,
>
> > since #9666 (SSI-tagvariable resolving) got accepted by Jacob lately
> > Hi,
>
> > I would like to restart discussion about the same functionality for
> > theurltemplatetag(as was already proposed in #7917).
>
> > Pro arguments:
> > - Theurltagis one of the few remaining tags that doesn't accept a
> > variable as it's "main" argument and is therefore inconsistent
> > behaviour.
> > - Allowing variables would enable the use in inclusion tags (e.g. a
> > pagination inclusiontagwhich takes a view name as argument - leading
> > behaviour.
> > - Allowing variables would enable the use in inclusion tags (e.g. a
> > to cleaner urls without get parameters with is beneficial for caching
> > etc.) .
> > - Generally reducing DRY in templates with similar content but
> > different links.
>
> > Contra arguments:
> > - Possible name clashes between views and template variables.
> > - May possibly lead to difficult to track down behaviour.
>
> I was one of the original people in favour of making this change, but
> since it was decided not to go down that path (disappointingly, it
> seems, mostly through apathy at the time), I think we shouldn't change
> it now. the fact that it will either require a backwards-incompatible
> syntax change or lead to ambiguity as to whether a view or string is
> intended is a big enough negative to think it's not worth doing.
> Particularly a you're proposing a system that changes the behaviour in
> every single release for the next three releases.
>
> Make no mistake, I would love to fix it properly, but I think the better
> approach is to introduce a newtagand then deprecate the old one, where
> > etc.) .
> > - Generally reducing DRY in templates with similar content but
> > different links.
>
> > Contra arguments:
> > - Possible name clashes between views and template variables.
> > - May possibly lead to difficult to track down behaviour.
>
> I was one of the original people in favour of making this change, but
> since it was decided not to go down that path (disappointingly, it
> seems, mostly through apathy at the time), I think we shouldn't change
> it now. the fact that it will either require a backwards-incompatible
> syntax change or lead to ambiguity as to whether a view or string is
> intended is a big enough negative to think it's not worth doing.
> Particularly a you're proposing a system that changes the behaviour in
> every single release for the next three releases.
>
> Make no mistake, I would love to fix it properly, but I think the better
> the newtaghandles strings consistently.
Reply all
Reply to author
Forward
0 new messages