Re: FOR template tag improvement
I think it's not that pythonic as it's just another syntax to do a thing that we are already able to do with the current syntax. -1. -- Vinicius Mendes Globo.com On Tue, Mar 29, 2011 at 9:19 PM, Alex Gaynor wrote: > > > On Tue, Mar 29, 2011 at 7:19 PM, Russell Keith-Magee < > russ...@keith-magee.com> wrote: > >> On Tue, Mar 29, 2011 at 10:32 PM, Mikoskay wrote: >> > It's rather difficult to provide specific use case for something that is >> a >> > convenience-related proposal. :) >> >> The opposite should be true. If this is a proposal that is so >> convenient, there must be many ways in which it could be used. >> >> To me, this smells like an attempt to introduce business logic into >> your templates, which is something Django discourages. >> >> A clear use case that demonstrates otherwise might help to counter >> this argument; absent of such an example, I'm -1 to this as well. >> >> 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-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. >> >> > I don't see how this is business logic. I do however see how it's totally > extraneous. -1. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > > > -- > 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: get_object_or_404 hook
You can always create your own convenience method. Atenciosamente, Vinicius Mendes Engenheiro de Computação Globo.com On Fri, Jun 3, 2011 at 12:30 AM, Justin Holmes wrote: > For every convenience method, there are always ways to make it even more > convenient. > > I think that if the needs are other than the very most typical use case > (ie, get_object_or_404) than a try block is indicated. > > > On Thu, Jun 2, 2011 at 10:31 PM, waylybaye wrote: > >> Hi guys, how about add a hook to get_object_or_404 to render a >> template with the same name of model when object does not exist ? >> >> For example: >> user = get_object_or_404(User, pk=pk) >> >> if the user does not exist, get_object_or_404 will try to render "404/ >> user.html" to show the error page other than a single 404 page for all >> queries. >> It's very useful I think. >> >> -- >> 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. >> >> > > > -- > Justin Holmes > > Head Instructor, SlashRoot Collective > SlashRoot: Coffee House and Tech Dojo > 60 Main Street > New Paltz, NY 12561 > 845.633.8330 > > > -- > 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.
Option to disable messages in auth context processor
Hi guys, I didn't like the messages buit-in contrib/auth application. That's
becouse of two points:
- It don't give the ability to send messages to anonymous users (I saw that
it is one of the planned features for 1.1);
- There's no way to distinguish the messages. For example: I like my success
messages displayed differently from my fail messages, and it isn't possible.
So I decided to write a new messages app and it works very well, the only
problem is the django.core.context_processors.auth. It simply hits the
database in every request and I don't want this since I am not using these
messages. So I changed the context processor to take a
variable(AUTH_USE_MESSAGES) from settings and call or not the function that
reads the messages from database.
I read the docs about contributing to django and there is a part saying that
if the patch is non trivial, what I think it is becouse there's a dozen of
ways to achieve this, you have to discuss it first in this list. So I am
doing this.
Another idea I had is to write three diferent context processors, one to
read the user, one for the messages and another for the perms. It is just
another idea. I am attaching the patch so you can see it.
Vinícius Mendes
Engenheiro de Computação
Meio Código - A peça que faltava para o seu código!
URL http://www.meiocodigo.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
-~--~~~~--~~--~--~---
Index: django/core/context_processors.py
===
--- django/core/context_processors.py (revisão 9814)
+++ django/core/context_processors.py (cópia de trabalho)
@@ -24,7 +24,7 @@
user = AnonymousUser()
return {
'user': user,
-'messages': user.get_and_delete_messages(),
+'messages': user.get_and_delete_messages() if getattr(settings, 'AUTH_USE_MESSAGES', True) else [],
'perms': PermWrapper(user),
}
Cache related values without needing to hit database twice
I think ORM should have some kind of caching. For example, in docs[1], when we do: >>> e = Entry.objects.get(pk=1) >>> e.blog # Hits database >>> e.blog # Don't hit database But let's imagine we have a third model named Author: class Author(models.Model): name = models.CharField(max_length=50) blog = models.OneToOneField(Blog) When we do: >>> a = Author.objects.get(pk=1) >>> b = a.blog # Hit's database >>> b.author # Hits database again What do you think in saving the author value in the blog instance if it is achieved through the author instance? It's something like telling blog who is his author in the moment you are retrieving it from the author. The same concept can be used in ForeignKey also. Whe we do: >>> b = Blog.objects.get(pk=1) >>> for entry in b.entry_set.all(): ...entry.blog # hits database to retrieve the blog in each iteration. What do you think about it? Vinícius Mendes Engenheiro de Computação Meio Código - A peça que faltava para o seu código! URL http://www.meiocodigo.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 -~--~~~~--~~--~--~---
Changeset 10219 does not fix #9587
In the ticket description, the user says that he is using inlineformset_factory, so do I. The changeset only fixes the FormSet. ModelFormSet and InlineFormSet are still bugged. In the methods save_new_objects and save_existing_objects, you have to check if the form is marked for deletion, if so, delete the object or don't save it (in case of saving new objects). The framework is checking if the form is marked for deletion in cleaned_data, but the cleaned_data isn't created for invalid forms. I wrote a patch to solve this problem and was thinking about reopening the ticket, but always, when somebody reopens a ticket in the TRAC, commiters ask him to send an e-mail to de developers list. What do you think about reopening the ticket? Vinícius Mendes Engenheiro de Computação Meio Código - A peça que faltava para o seu código! URL http://www.meiocodigo.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 -~--~~~~--~~--~--~---
i18n for permissions names in auth
I was thinking that it would be a good feature if the names of the auth permissions could be internationalizated. For example, instead of storing 'Can add user' in database, can store something like 'Can add %(model_verbose_name)s'. And then internationalize it for the user and put the model name in the place of %(model_verbose_name)s. It is just an example of implementation, but i think it is not the better. What do you think about the feature? And what about suggestions for the implementation? Vinícius Mendes Engenheiro de Computação Meio Código - A peça que faltava para o seu código! URL http://www.meiocodigo.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: Cache related values without needing to hit database twice
Yes, i think it is what is described in this ticket, but a little different, would be something automatic. If i retrieve a value from one instance, then, the reverse relation field has to be automatically populated. On Mar 10, 2:09 pm, Jeremy Dunck wrote: > On Tue, Mar 10, 2009 at 11:12 AM, Vinicius Mendes wrote: > > ... > > > What do you think in saving the author value in the blog instance if it is > > achieved through the author instance? It's something like telling blog who > > is his author in the moment you are retrieving it from the author. > > You're describing ye olde #17:http://code.djangoproject.com/ticket/17 --~--~-~--~~~---~--~~ 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: Changeset 10219 does not fix #9587
I didn't understand. Line 216 is the docstring: """ Returns True if form.errors is empty for every form in self.forms. """ I don't want to create the cleaned data. I just adopted the same logic used in the patch to solve the problem. If the form doesn't have a cleaned_data attr, so I get it from the field, and check it. All the changes were made in the django/forms/models.py In the methods save_existing_objects and save_new_objects. On Mar 31, 2:35 pm, Alex Gaynor wrote: > On Tue, Mar 31, 2009 at 1:32 PM, Vinicius Mendes wrote: > > In the ticket description, the user says that he is using > > inlineformset_factory, so do I. The changeset only fixes the FormSet. > > ModelFormSet and InlineFormSet are still bugged. In the methods > > save_new_objects and save_existing_objects, you have to check if the form is > > marked for deletion, if so, delete the object or don't save it (in case of > > saving new objects). > > > The framework is checking if the form is marked for deletion in > > cleaned_data, but the cleaned_data isn't created for invalid forms. I wrote > > a patch to solve this problem and was thinking about reopening the ticket, > > but always, when somebody reopens a ticket in the TRAC, commiters ask him to > > send an e-mail to de developers list. > > > What do you think about reopening the ticket? > > > > > > Vinícius Mendes > > Engenheiro de Computação > > Meio Código - A peça que faltava para o seu código! > > URLhttp://www.meiocodigo.com > > Look at line 216 of formsets.py it specifically makes sure not to interogate > cleaned_data. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." --Voltaire > "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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: Changeset 10219 does not fix #9587
Look at this link: http://code.djangoproject.com/browser/django/trunk/django/forms/formsets.py I think your revision isn't the HEAD of trunk. The comment you said is in lines 227-229. But the point here isn't create a cleaned_data for the form. I know it will not exist. The problem is that this will cause problems in lines 428 and 447 of models.py ( http://code.djangoproject.com/browser/django/trunk/django/forms/models.py ). I wrote a little patch, if you want to take a look, you will understand what I am saying. The diff is here: http://dpaste.com/21753/ On Mar 31, 2:41 pm, Alex Gaynor wrote: > On Tue, Mar 31, 2009 at 1:39 PM, Vinicius Mendes | meiocodigo.com < > > > > vbmen...@gmail.com> wrote: > > > I didn't understand. Line 216 is the docstring: > > > """ > > Returns True if form.errors is empty for every form in self.forms. > > """ > > > I don't want to create the cleaned data. I just adopted the same logic > > used in the patch to solve the problem. If the form doesn't have a > > cleaned_data attr, so I get it from the field, and check it. All the > > changes were made in the django/forms/models.py In the methods > > save_existing_objects and save_new_objects. > > > On Mar 31, 2:35 pm, Alex Gaynor wrote: > > > On Tue, Mar 31, 2009 at 1:32 PM, Vinicius Mendes > > wrote: > > > > In the ticket description, the user says that he is using > > > > inlineformset_factory, so do I. The changeset only fixes the FormSet. > > > > ModelFormSet and InlineFormSet are still bugged. In the methods > > > > save_new_objects and save_existing_objects, you have to check if the > > form is > > > > marked for deletion, if so, delete the object or don't save it (in case > > of > > > > saving new objects). > > > > > The framework is checking if the form is marked for deletion in > > > > cleaned_data, but the cleaned_data isn't created for invalid forms. I > > wrote > > > > a patch to solve this problem and was thinking about reopening the > > ticket, > > > > but always, when somebody reopens a ticket in the TRAC, commiters ask > > him to > > > > send an e-mail to de developers list. > > > > > What do you think about reopening the ticket? > > > > > > > > > > Vinícius Mendes > > > > Engenheiro de Computação > > > > Meio Código - A peça que faltava para o seu código! > > > > URLhttp://www.meiocodigo.com > > > > Look at line 216 of formsets.py it specifically makes sure not to > > interogate > > > cleaned_data. > > > > Alex > > > > -- > > > "I disapprove of what you say, but I will defend to the death your right > > to > > > say it." --Voltaire > > > "The people's good is the highest law."--Cicero > > Not the line 216 i see, but to save trouble here's the full comment: > > 215 # The way we lookup the value of the deletion field here > takes 216 # more code than we'd like, but the form's > cleaned_data will 217 # not exist if the form is invalid. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." --Voltaire > "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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: Changeset 10219 does not fix #9587
Here is the problem demonstration: http://dpaste.com/21801/ On Mar 31, 3:06 pm, Alex Gaynor wrote: > On Tue, Mar 31, 2009 at 1:55 PM, Vinicius Mendes | meiocodigo.com < > > > > vbmen...@gmail.com> wrote: > > > Look at this link: > > >http://code.djangoproject.com/browser/django/trunk/django/forms/forms... > > > I think your revision isn't the HEAD of trunk. The comment you said is > > in lines 227-229. But the point here isn't create a cleaned_data for > > the form. I know it will not exist. The problem is that this will > > cause problems in lines 428 and 447 of models.py ( > >http://code.djangoproject.com/browser/django/trunk/django/forms/model... > > ). I wrote a little patch, if you want to take a look, you will > > understand what I am saying. The diff is here: > > >http://dpaste.com/21753/ > > > On Mar 31, 2:41 pm, Alex Gaynor wrote: > > > On Tue, Mar 31, 2009 at 1:39 PM, Vinicius Mendes | meiocodigo.com < > > > > vbmen...@gmail.com> wrote: > > > > > I didn't understand. Line 216 is the docstring: > > > > > """ > > > > Returns True if form.errors is empty for every form in self.forms. > > > > """ > > > > > I don't want to create the cleaned data. I just adopted the same logic > > > > used in the patch to solve the problem. If the form doesn't have a > > > > cleaned_data attr, so I get it from the field, and check it. All the > > > > changes were made in the django/forms/models.py In the methods > > > > save_existing_objects and save_new_objects. > > > > > On Mar 31, 2:35 pm, Alex Gaynor wrote: > > > > > On Tue, Mar 31, 2009 at 1:32 PM, Vinicius Mendes > > > > wrote: > > > > > > In the ticket description, the user says that he is using > > > > > > inlineformset_factory, so do I. The changeset only fixes the > > FormSet. > > > > > > ModelFormSet and InlineFormSet are still bugged. In the methods > > > > > > save_new_objects and save_existing_objects, you have to check if > > the > > > > form is > > > > > > marked for deletion, if so, delete the object or don't save it (in > > case > > > > of > > > > > > saving new objects). > > > > > > > The framework is checking if the form is marked for deletion in > > > > > > cleaned_data, but the cleaned_data isn't created for invalid forms. > > I > > > > wrote > > > > > > a patch to solve this problem and was thinking about reopening the > > > > ticket, > > > > > > but always, when somebody reopens a ticket in the TRAC, commiters > > ask > > > > him to > > > > > > send an e-mail to de developers list. > > > > > > > What do you think about reopening the ticket? > > > > > > > > > > > > > > Vinícius Mendes > > > > > > Engenheiro de Computação > > > > > > Meio Código - A peça que faltava para o seu código! > > > > > > URLhttp://www.meiocodigo.com > > > > > > Look at line 216 of formsets.py it specifically makes sure not to > > > > interogate > > > > > cleaned_data. > > > > > > Alex > > > > > > -- > > > > > "I disapprove of what you say, but I will defend to the death your > > right > > > > to > > > > > say it." --Voltaire > > > > > "The people's good is the highest law."--Cicero > > > > Not the line 216 i see, but to save trouble here's the full comment: > > > > 215 # The way we lookup the value of the deletion field > > here > > > takes 216 # more code than we'd like, but the form's > > > cleaned_data will 217 # not exist if the form is invalid. > > > > Alex > > > > -- > > > "I disapprove of what you say, but I will defend to the death your right > > to > > > say it." --Voltaire > > > "The people's good is the highest law."--Cicero > > No, my comments weren't directed at trunk, but neither was the commit you > referenced. You'll need a failing test case(probably just trying to call > save on a formset like the ones in the tests). > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." --Voltaire > "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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: Changeset 10219 does not fix #9587
Joseph, I think the problem is still the same of the reported in the ticket, since the reporter talks about inlineformset_factory, so he is using InlineFormsets. Did you see the patch I put in dpaste? http://dpaste.com/21753/ It's basically the same idea used in the changeset. On Mar 31, 3:35 pm, Joseph Kocherhans wrote: > On Tue, Mar 31, 2009 at 12:32 PM, Vinicius Mendes wrote: > > > In the ticket description, the user says that he is using > > inlineformset_factory, so do I. The changeset only fixes the FormSet. > > ModelFormSet and InlineFormSet are still bugged. In the methods > > save_new_objects and save_existing_objects, you have to check if the form is > > marked for deletion, if so, delete the object or don't save it (in case of > > saving new objects). > > > The framework is checking if the form is marked for deletion in > > cleaned_data, but the cleaned_data isn't created for invalid forms. I wrote > > a patch to solve this problem and was thinking about reopening the ticket, > > but always, when somebody reopens a ticket in the TRAC, commiters ask him to > > send an e-mail to de developers list. > > > What do you think about reopening the ticket? > > You're right. The changeset only fixes plain formsets, not model formsets or > inline formsets. Normally, I'd say open a new ticket since it's a different > problem, but I'll work on a patch right now. A new ticket would just be > extra bookkeeping. I didn't understand, you think is better reopen the ticket, open a new ticket or don't do anything? > > Joseph --~--~-~--~~~---~--~~ 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: Changeset 10219 does not fix #9587
It seems to be ok! Thanks On Mar 31, 4:59 pm, Joseph Kocherhans wrote: > On Tue, Mar 31, 2009 at 1:57 PM, Vinicius Mendes | meiocodigo.com < > > > > vbmen...@gmail.com> wrote: > > On Mar 31, 3:35 pm, Joseph Kocherhans wrote: > > > On Tue, Mar 31, 2009 at 12:32 PM, Vinicius Mendes > >wrote: > > > > > What do you think about reopening the ticket? > > > > You're right. The changeset only fixes plain formsets, not model formsets > > or > > > inline formsets. Normally, I'd say open a new ticket since it's a > > different > > > problem, but I'll work on a patch right now. A new ticket would just be > > > extra bookkeeping. > > > I didn't understand, you think is better reopen the ticket, open a new > > ticket or don't do anything? > > Alex is right. I was saying not to do anything. I just checked in a fix [1]. > Please open a new ticket if you are still having problems. > > Joseph > > [1]http://code.djangoproject.com/changeset/10283 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
