ticket #7239, Using the url tag with the blocktrans one

[David Larlet]

Hello,

I had just updated the patch which handles the new policy introduced
in r8211 (good one!), if one of the core dev could take a look at it
(it has been marked as RFC). I think it's an important addition for
1.0, otherwise it's really hard to do not repeat yourself in an
i18nized templates. This new "feature" is fully compatible with the
existing blocktrans tag.

http://code.djangoproject.com/ticket/7239

Thanks,
David

[Jannis Leidel]

Hi David,

I totally agree, this would make writing sane templates much easier.
Given the serious limitations when using named URLs in translated
templates with the url template tag, I would even say it's more a bug
fix than a new feature.

At Pinax [1] we use the captureas template tag [2] as a workaround
which is undoubtful nasty and definitely un-DRY.

Best,
Jannis

1: http://pinaxproject.com/
2: http://www.djangosnippets.org/snippets/545/

[Malcolm Tredinnick]

I'll look at this in the next couple of days -- today and tomorrow are
already busy -- and probably commit it before the beta (otherwise it
will wait until after 1.0). I suspect any solution to this is going to
be a slight compromise and I'm not entirely in love with the approach
there, but I haven't seen (or been able to think of) anything else that
doesn't look just as messy.

Regards,
Malcolm

[Julien Phalip]

Just a thought, the same approach would be valuable with the 'with'
tag:

{% with url path.to.some_view arg1,arg2,name1=value1 as myurl %}
This is a <a href="{{ myurl }}" title="">link</a>.
{% endwith %}

Regards,

Julien

On Aug 11, 1:17 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

[Malcolm Tredinnick]

On Sun, 2008-08-10 at 15:00 -0700, Julien Phalip wrote:
> Just a thought, the same approach would be valuable with the 'with'
> tag:
>
> {% with url path.to.some_view arg1,arg2,name1=value1 as myurl %}
> This is a <a href="{{ myurl }}" title="">link</a>.
> {% endwith %}

No, you can't have a pony.

Please let's keep threads like this one (and similar "getting ready for
1.0" ones) on-topic. We're down to counting the hours until we have to
be ready for 1.0-beta. This thread is about a significant i18n
requirement for 1.0, not a minor typing saver that can wait until after
1.0 or even the end of time without things being significantly worse
off.

Yes, it's just a wishlist item. But it's also yet another email that
somebody trying to work through this thread needs to realise is not
actually on-topic.

Thanks,
Malcolm

[Julien Phalip]

On Aug 11, 10:04 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

Hi,

I don't think that my thought was completely off-topic here. I was
only trying to add to the discussion, not just add a random item on
the wish list.

Extending the 'with' tag syntax would allow you to wrap {% blocktrans
%} with a {% with url .... as myurl %}. That way, you wouldn't need to
change the blocktrans tag syntax at all, and more, you could re-use
that functionality in many other situations where {% with %} can be
applied.

If you think this is a bad idea or that what I suggest above is not
achievable, then I'm sorry. By no means did I want to clutter this
thread with irrelevant ideas.

Regards,

Julien

[Malcolm Tredinnick]

On Sun, 2008-08-10 at 17:31 -0700, Julien Phalip wrote:
[...]

> Extending the 'with' tag syntax would allow you to wrap {% blocktrans
> %} with a {% with url .... as myurl %}. That way, you wouldn't need to
> change the blocktrans tag syntax at all, and more, you could re-use
> that functionality in many other situations where {% with %} can be
> applied.

Fair enough. It wasn't clear, at least to me, that that was what you
were proposing (although expanding the use of "with" outside the
blocktrans is definitely pony country). It requires a change in the way
blocktrans work and the "with" tag is now being overloaded, which is a
bit of a slippery slope. Putting tags inside other tags is just
generally ugly, so a different block tag would be a better solution
here. That's why we talked about something like a hypothetical
"with-block" tag in one of the earlier threads.

Regards,
Malcolm

[Julien Phalip]

> Fair enough. It wasn't clear, at least to me, that that was what you
> were proposing (although expanding the use of "with" outside the
> blocktrans is definitely pony country).

My apologies, I was indeed not very clear in my first post.

> It requires a change in the way
> blocktrans work and the "with" tag is now being overloaded, which is a
> bit of a slippery slope. Putting tags inside other tags is just
> generally ugly, so a different block tag would be a better solution
> here. That's why we talked about something like a hypothetical
> "with-block" tag in one of the earlier threads.

I always thought that the creation of variables within templates
wasn't very pythonic in the sense "There shouldn't be more than one
way to do something". Currently, both {% blocktrans %} and {% with %}
can create variables. My preference would be to let {% blocktrans %}
focus on its job for internationalisation, and move all the variable
creation to a single, dedicated for that purpose, tag (maybe 'with'?).

[Julien Phalip]

Just following up on the 'with-block' idea. Here's a suggested syntax:

{% withblock as myurl %}
{% url path.to.some_view arg1,arg2,name1=value1 %}
{% in %}
{% blocktrans %}

This is a <a href="{{ myurl }}" title="">link</a>.

{% endblocktrans %}
{% endwithblock %}

Very much like the {% captureas %} tag mentioned above, but a bit
prettier as it would limit the variable life to the given {% in %}
block. Plus, that would give a single and generic way to create block
variables. What if we later find other use cases than just passing
URL's to a blocktrans?

[David Larlet]

Le 11 août 08 à 03:33, Julien Phalip a écrit :

>
> Just following up on the 'with-block' idea. Here's a suggested syntax:
>
> {% withblock as myurl %}
> {% url path.to.some_view arg1,arg2,name1=value1 %}
> {% in %}
> {% blocktrans %}
> This is a <a href="{{ myurl }}" title="">link</a>.
> {% endblocktrans %}
> {% endwithblock %}
>
> Very much like the {% captureas %} tag mentioned above, but a bit
> prettier as it would limit the variable life to the given {% in %}
> block. Plus, that would give a single and generic way to create block
> variables. What if we later find other use cases than just passing
> URL's to a blocktrans?

It looks interesting but I can't see how you define more than one
variable with this syntax.

I agree that the current implementation has cons and lack of some
genericity, we had chatted about that with Jannis before and the patch
is the best compromise we found (the other one is to allow all tags in
blocktrans definition which is not backward incompatible with the
proposed one). We discuss about that for months and I think that's
better than nothing to have at least an extended blocktrans tag. If
another solution comes up in the next months, that's great but during
this time we'll be able to use it (hopefully in 1.0).

Best,
David

[Julien Phalip]

> It looks interesting but I can't see how you define more than one  
> variable with this syntax.

Good point. Here's a revised syntax suggestion:

{% withblock as myurl1 %}

{% url path.to.some_view arg1,arg2,name1=value1 %}

{% andblock as myurl2 %}
{% url path.to.some_other_view arg1,arg2,name1=value1 %}

{% in %}
{% blocktrans %}

This is a <a href="{{ myurl1 }}" title="">link</a>.
This is another <a href="{{ myurl2 }}" title="">link</a>.

[Julien Phalip]

Hi there,

I gave it a go and created a ticket with a suggested withblock tag.
http://code.djangoproject.com/ticket/8297

You can have a look and see if that can help in this situation.

Cheers,

Julien ;)

[David Larlet]

Le 14 août 08 à 00:41, Julien Phalip a écrit :

>
> Hi there,
>
> I gave it a go and created a ticket with a suggested withblock tag.
> http://code.djangoproject.com/ticket/8297
>
> You can have a look and see if that can help in this situation.

Well, to be honest, I'm not fond of this solution which is very verbose.
On the other hand, if we'd like to see this in 1.0 we need to take a
decision. Malcolm seemed to be +0 (correct me if I'm wrong), Jannis +1
on the initial implementation, any one else strongly against the
extension of blocktrans?

David

[Malcolm Tredinnick]

I've looked at it some more and reviewed the patch. I'm not comfortable
rushing it in at the moment because the API really is a bit dubious
still. We can still add stuff in a backwards-compatible fashion after
1.0, so it's being punted for now. Sorry, but time has run out.

The more I look at all those things that are tags without looking like
tags in the blocktrans tag, the more it looks messy (particularly as you
cannot break a tag over multiple lines). Something like #8297 but with a
better syntax feels more Django-y and Pythonic. So play with that a bit
if you like, but the code is post-1.0 for now.

Regards,
Malcolm