Re: Template Tag Not Reinitialized in Loop
I bet context['page'] is different each time, but the tag
initialization is called only once.
So it's probably your programming error, not a bug in django.
On Tue, May 11, 2010 at 1:29 AM, patrick91 wrote:
> I've this problem too
>
> I created a custom template tag that renders info about a model
>
> but when I use that tag in a for the tag is used just one time. Like
> this
>
> {% for page in pages %}
> {% show_info page %}
> {% endfor %}
>
> ---
>
> page info #1
> page info #1
> page info #1
>
> should I provide my custom template tag code?
>
>
> Thanks for any reply :)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, 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-develop...@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.
TestCase, urlresolvers.reverse and DB
Hello,
I encountered a problem while writing some django tests on the svn
version. Whenever I call reverse(urlname), the db is emptied.
Here is the code:
1 from django.contrib.auth.models import User
2 from django.test import TestCase
3 from django.core.urlresolvers import reverse
4
5 class UsersTests(TestCase):
6 def setUp(self):
7 self.john = User.objects.create_user('john',
'j...@example.com', '123456')
8 self.jack = User.objects.create_user('jack',
'j...@example.com', '7891011')
9
10 def test_reverse(self):
11 print __file__, 1, User.objects.all()
12 link = reverse('homepage')
13 print __file__, 2, User.objects.all()
And the output is:
userprofile/tests.py 1 [, ]
userprofile/tests.py 2 []
.
--
Ran 1 test in 0.261s
Is this the expect output with the updates to django test framework? I
dont understand why this happens...
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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: TestCase, urlresolvers.reverse and DB
On Tue, May 11, 2010 at 10:23 AM, Liviu Chiributa wrote: > I encountered a problem while writing some django tests on the svn > version. Whenever I call reverse(urlname), the db is emptied. > > Here is the code: I just tried out this exact same code, and it works fine for me with both the RC and latest trunk (r13237). I get, as expected:: /Users/jacob/Projects/jacobian.org/jacobian/blog/tests.pyc 1 [, ] /Users/jacob/Projects/jacobian.org/jacobian/blog/tests.pyc 2 [, ] So there's probably something strange going on that's specific to your setup. You should probably take this to django-users -- someone there can probably help you track down what's wrong with your code. If you're able to prove that it's a problem with Django, bring it on back here and we'll take another look. Thanks! Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: django.db.models.Options contribute_to_class uses default connection instead of using DATABASE_ROUTERS
> > The imported connection is never used in the method, > > Look closer - it is used, right at the end of contribute_to_class. The > connection is used to get the operations module for the backend, which > is then used to determine if the generated database table name needs > to be truncated. Oops. I thought that was part of the #6148 patch. :) > Sounds like a bug in the patch to me. As I said earlier, the options > class doesn't have any knowledge about the database that is being used > for a specific operation, so it can't enforce per-database > restrictions. In the case of db_table truncation, I suspect the right > approach here is to store db_table as an untruncated string, and then > truncate it at time of use inside specific backends or in queries. I > suspect analogous changes will be required for #6148. > > This should also be logged as a bug; the truncation behavior that is > currently implemented is definitely wrong. Thanks for the information. I will log a bug regarding the db_table truncation and reference this thread in it. Hopefully I will be able to describe the problem adequately. I will also raise the issue on ticket #6148. I have a feeling the code contributed to this method by the patch for #6148 will just need to be removed. The side effect being a lot of dependent code would need to change. The patch adds what appears to be a convenience member called qualified_name that is constructed by using another new member db_schema and db_table. It calls connections.ops.prep_db_table(self.db_schema, self.db_table) which combines them in a db specific manner and qualified_name is set from the resulting string. I am not sure where else this member could be initialized where it would have access to the correct connection. Sounds more likely that it must just be removed and constructed every were a table name is needed. It occurred to me to turn qualified_name into a "lazy loaded" member using a getter and a property(…) on Options, but as you point out it still needs a connection and in addition it appears the correct way to get a connection is to "ask" a router what connection to use for a given Model instance. Since Options is part of a Model instance's _meta instance I am not sure how I would call router.db_for_read() from a Options getter method. Peter Long -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Class based generic views in 1.3?
On 11 touko, 03:37, Russell Keith-Magee wrote: > show us the code!. > > [1] > http://github.com/jacobian/django/tree/class-based-generic-views/django/views/generic2 Yes, well. I have been in slight assumption that the above code is the one that will be merged. Though if it needs to be improved, I think Jacobian could *list the problems in his implementation* so others can try to improve on them, as he probably knows that code best. >From that point of view, I don't see a reason in rewriting the class based generic-views as there is already Jacobian's take on 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-develop...@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: Class based generic views in 1.3?
On Wed, May 12, 2010 at 1:35 AM, Jari Pennanen wrote: > > On 11 touko, 03:37, Russell Keith-Magee > wrote: >> show us the code!. >> >> [1] >> http://github.com/jacobian/django/tree/class-based-generic-views/django/views/generic2 > > Yes, well. I have been in slight assumption that the above code is the > one that will be merged. Though if it needs to be improved, I think > Jacobian could *list the problems in his implementation* so others can > try to improve on them, as he probably knows that code best. > > From that point of view, I don't see a reason in rewriting the class > based generic-views as there is already Jacobian's take on it. If you look at Jacob's code, you'll discover that Jacob's implementation isn't complete. The edit views are still just stubs. I've also seen comments about consistency between Jacob's implementation and the class-based syndication views that are in trunk. That means there is still work to do, and someone needs to do it. If you're going to volunteer to do the work, I don't think Jacob would complain about getting assistance. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
NB: New leader in group posting
After years of Malcolm's legend response rate leading the chart, I'm pleased to point out that there's a new name in all-time most-posted to django-developers: http://groups.google.com/group/django-developers/about (It is my hope that this sly ploy brings Malcolm back to activity.) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: NB: New leader in group posting
On Wed, May 12, 2010 at 8:18 AM, Jeremy Dunck wrote: > After years of Malcolm's legend response rate leading the chart, I'm > pleased to point out that there's a new name in all-time most-posted > to django-developers: > http://groups.google.com/group/django-developers/about So... where do I collect my fabulous prizes? :-) Russ %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
