Re: Reversing translated urls in templates
What about not implementing this as a url tag but as a translation-
override tag? Then it is not only possible to specify the language to
use for your URL translation, but as well for other translatable
content. Example:
{% transoverride language_code %}
{% trans "Register account" %}: {% url account:register %}
{% endtransoverride %}
Orne
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Reversing translated urls in templates
I think {% transurl account:register %} would be more convenient to work
with i18n_patterns
On 3 July 2011 10:42, brocaar wrote:
> What about not implementing this as a url tag but as a translation-
> override tag? Then it is not only possible to specify the language to
> use for your URL translation, but as well for other translatable
> content. Example:
>
>{% transoverride language_code %}
>{% trans "Register account" %}: {% url account:register %}
>{% endtransoverride %}
>
>
> Orne
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Resetting cache gracefully at the end of every test?
> > I believe as a general principle that a testing framework should always > return the system under test to the state it was in prior to the run. > Calling cache.flush() violates that principle -- and of principle concern to > me, it flushes your *entire* cache. That means if someone executed tests in > production it could kill an entire cache, a situation which could be > slightly annoying or a horrific headache depending. > > Of course, if no one else agrees with me that this is a worthy principle > for Django tests then I won't waste anyone's time by undertaking a patch :) I'd like to +1 on the whole idea. Making the testing framework use a special key prefix when saving/getting values from cache during test run (a key prefix such as "test_", which is equivalent to adding the "test_" prefix for DB names, as pointed out by Jim) and reset all records saved in cache during test run would not only ensure that tests are not polluting "real cache" with dummy values and are not altering legitimate values in cache, it would also ensure that tests are run within a pristine cache. That is, it would prevent tests from interacting with some cache values which would have been saved outside the test run (during normal system run or during a previous test run, for instance), i.e. it would prevent tests from being sensitive to cache state. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Named tuples queryset
Hello. I've added an implementation for named tuples query set, see https://code.djangoproject.com/ticket/15648 - Named tuples could be iterated over with order saving (like lists / tuples). - Properties there could be accessed with dot notation - post.topic (almost like dicts). - They could be converted both to dicts and lists - Easy debugging (pros over queryset.deferred()) - I've provided a fallback implementation of named tuple for python 2.5 users - Tests are there too. Named tuples eliminate neediness in values & values_list because they have all their features. What do you think about it? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Reversing translated urls in templates
On Monday, July 4, 2011 1:42:37 AM UTC+12, brocaar wrote:
>
> What about not implementing this as a url tag but as a translation-
> override tag? Then it is not only possible to specify the language to
> use for your URL translation, but as well for other translatable
> content. Example:
>
> {% transoverride language_code %}
> {% trans "Register account" %}: {% url account:register %}
> {% endtransoverride %}
>
>
That does have the advantage of being more flexible even in just the context
of urls. For example, referring to a url via {{ obj.get_absolute_url }}.
+1 for more flexibility.
That's one ugly tag name though :D
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/F-ICvrsxqqMJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Named tuples queryset
Hi Paul, Is it correct that nametuple construction is much slower than for normal ones or is this true only in older python versions? On Mon, Jul 4, 2011 at 1:47 AM, paulpmillr wrote: > Hello. > > I've added an implementation for named tuples query set, see > https://code.djangoproject.com/ticket/15648 > > - Named tuples could be iterated over with order saving (like lists / > tuples). > - Properties there could be accessed with dot notation - post.topic > (almost like dicts). > - They could be converted both to dicts and lists > - Easy debugging (pros over queryset.deferred()) > - I've provided a fallback implementation of named tuple for python > 2.5 users > - Tests are there too. > > Named tuples eliminate neediness in values & values_list because they > have all their features. > > What do you think about it? -- Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
Umm... How about now? I've been bitten by trailing/leading blank spaces in form inputs several times now, and I'm tired of monkey patching django to fix this. Thanks. Ryan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/qF5BK8fUsKMJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
