Re: newforms issues
On Mon, 2007-05-21 at 23:14 -0500, Gary Wilson wrote: > Malcolm Tredinnick wrote: > >> #3718 - newforms.Form.clean should have access to field errors [1] > > > > I'm not sure what this really gains. Fixing the second part of #3896 > > means that all the necessary information is in cleaned_data. I'm -0 on > > this, because I feel it's pretty pointless, merely providing more than > > one way to do something (not a good thing). > > > > Now convince me I'm wrong. What use-case have I overlooked? > > I would say that checking the errors property should be the one way to > see if there have been errors, not checking that every field in my model > has a key in cleaned_data. Without access to errors, you're going to > have one hell of an if statement with even a small form. Only if you code it badly. A for loop over self.cleaned_data works. > Add in > non-required fields and things get ugly even faster since it's not an > error if a non-required field has no key in cleaned_data. *shrug* In most cases you're going to have to access self.fields in any case. I'm still -0. But that really is -0 -- I have a slight preference, but I'll manage to keep on living whichever way it goes; quite happily, too. :-) > > Add in a subclass and now you've got the subclass having to know the > fields of the base class(es). Either that or a for loop looping through > self.base_fields to check that every field is in cleaned_data. Again, > getting even uglier with non-required fields. > > >> #3896 - pass value to field specific clean function [2] > > > > Grr...don't put two issues in one ticket! > > > > I'm -1 on the first part because it's an unnecessary backwards > > incompatibility change for the most part. It's not like it's a massive > > performance improvement in an area that is currently slow. > > > > Definitely +1 on the second part, though. Removing the first assignment > > to self.cleaned_data would make a lot of sense. > > I could have created a new ticket for the "self.cleaned_data retaining > the value even if clean_XXX() fails" problem, but by taking out the > first assignment to self.cleaned_data you *have to* pass the field's > value to clean_XXX() since the value would no longer be in > self.cleaned_data for clean_XXX() to access it. I figured opening a new > ticket would not be worthwhile, I could have been wrong. I'm sort of convinced. I'd forgotten that you would access the value through cleaned_data. We could still fix it in a backwards compatible fashion: if clean_ raises a ValidationError remove the value from cleaned_data, but maybe it's not worth it. I'm 0 on the first part and +1 on the second, then (since we can fix the second without the first). Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms issues
Malcolm Tredinnick wrote: >> #3718 - newforms.Form.clean should have access to field errors [1] > > I'm not sure what this really gains. Fixing the second part of #3896 > means that all the necessary information is in cleaned_data. I'm -0 on > this, because I feel it's pretty pointless, merely providing more than > one way to do something (not a good thing). > > Now convince me I'm wrong. What use-case have I overlooked? I would say that checking the errors property should be the one way to see if there have been errors, not checking that every field in my model has a key in cleaned_data. Without access to errors, you're going to have one hell of an if statement with even a small form. Add in non-required fields and things get ugly even faster since it's not an error if a non-required field has no key in cleaned_data. Add in a subclass and now you've got the subclass having to know the fields of the base class(es). Either that or a for loop looping through self.base_fields to check that every field is in cleaned_data. Again, getting even uglier with non-required fields. >> #3896 - pass value to field specific clean function [2] > > Grr...don't put two issues in one ticket! > > I'm -1 on the first part because it's an unnecessary backwards > incompatibility change for the most part. It's not like it's a massive > performance improvement in an area that is currently slow. > > Definitely +1 on the second part, though. Removing the first assignment > to self.cleaned_data would make a lot of sense. I could have created a new ticket for the "self.cleaned_data retaining the value even if clean_XXX() fails" problem, but by taking out the first assignment to self.cleaned_data you *have to* pass the field's value to clean_XXX() since the value would no longer be in self.cleaned_data for clean_XXX() to access it. I figured opening a new ticket would not be worthwhile, I could have been wrong. >> #4271 - Form should use a copy of data passed to it [3] > > Make up your mind! You want to save a single variable access in #3896, > but do a whole dictionary copy every time here??! :-) > > I'm a bit torn about this, because QueryDict.copy() isn't free and the > use-case you mention in the bug isn't particularly common and isn't > currently impossibly to do at the moment, by doing the copy() in the > Form constructor. > > I'm probably -0 for that reason. Not something I feel particularly > strongly about, though. > >> #4297 - make BaseForm's __errors attribute non-private [4] > > Whoops. I thought I'd already changed this one to Accepted. Apparently > I'd only got as far as making the decision in my head. I agree with you > on this. I couldn't think of a reason to hide that value (and making it > "_errors", rather than "errors" is the right change). > > I worry about people who want to hide away error messages after the > fact, rather than fixing the problems in the right place (whatever > validation generated the errors), but that's their problem. We'll > provided shotguns and bullets if it's not too hard, they can provide the > feet and entertain themselves at will. It's not all about hiding error messages though. If I had a Form subclass that had a full_clean() that called its parent and then did some other things and created errors, now the __errors dict would be split into two mangled instance attributes (one for each class). Not fun. I like my forms fully loaded, thank you. Gary --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ticket feedback process
I was wondering what is the most appropriate way to get feedback on tickets that have been submitted (bugs and/or features)--through the ticket system itself or by starting a discussion on the developers list (after a ticket has been submitted)? Thanks, Casey --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms issues
On 5/21/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > #3896 - pass value to field specific clean function [2] > > Grr...don't put two issues in one ticket! > > I'm -1 on the first part because it's an unnecessary backwards > incompatibility change for the most part. It's not like it's a massive > performance improvement in an area that is currently slow. > > Definitely +1 on the second part, though. Removing the first assignment > to self.cleaned_data would make a lot of sense. This change would make things cleaner and obvious (as well as being the best way to fix the bug of cleaned_data having uncleaned values). I personally don't mind changing code and retesting for that purpose, but since many others do I'm +0. But I wanted to point out that the two changes are closely related, and both are needed to fix the bug. Applying the second change without the first would break any code that uses a clean_* method right now, and applying the first without the second would also break code as well as not actually fixing the bug. I am not sure that I didn't miss something obvious, though. If I did, please correct me, I would like to properly understand the proposed change. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms issues
On Tue, 2007-05-22 at 11:24 +1000, Malcolm Tredinnick wrote: > Hey Gary, > > On Mon, 2007-05-21 at 19:56 -0500, Gary Wilson wrote: [...] > > > #3896 - pass value to field specific clean function [2] > > Grr...don't put two issues in one ticket! > > I'm -1 on the first part because it's an unnecessary backwards > incompatibility change for the most part. It's not like it's a massive > performance improvement in an area that is currently slow. To be fair, I'll say I'm -0.5 on this change. Find somebody who's +1 and you're in the positive. It's not going to stop the world turning if we make the change and I'm possibly being overly-sensitive because I've been the recent target for people whining about backwards-incompat changes that were necessary. Regards, Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms issues
Hey Gary, On Mon, 2007-05-21 at 19:56 -0500, Gary Wilson wrote: > I would like to request comments/suggestions about a few patches I have > submitted recently for the newforms library that solve some issues that > I encountered during the development of some newforms. > > #3718 - newforms.Form.clean should have access to field errors [1] I'm not sure what this really gains. Fixing the second part of #3896 means that all the necessary information is in cleaned_data. I'm -0 on this, because I feel it's pretty pointless, merely providing more than one way to do something (not a good thing). Now convince me I'm wrong. What use-case have I overlooked? > #3896 - pass value to field specific clean function [2] Grr...don't put two issues in one ticket! I'm -1 on the first part because it's an unnecessary backwards incompatibility change for the most part. It's not like it's a massive performance improvement in an area that is currently slow. Definitely +1 on the second part, though. Removing the first assignment to self.cleaned_data would make a lot of sense. > #4271 - Form should use a copy of data passed to it [3] Make up your mind! You want to save a single variable access in #3896, but do a whole dictionary copy every time here??! :-) I'm a bit torn about this, because QueryDict.copy() isn't free and the use-case you mention in the bug isn't particularly common and isn't currently impossibly to do at the moment, by doing the copy() in the Form constructor. I'm probably -0 for that reason. Not something I feel particularly strongly about, though. > #4297 - make BaseForm's __errors attribute non-private [4] Whoops. I thought I'd already changed this one to Accepted. Apparently I'd only got as far as making the decision in my head. I agree with you on this. I couldn't think of a reason to hide that value (and making it "_errors", rather than "errors" is the right change). I worry about people who want to hide away error messages after the fact, rather than fixing the problems in the right place (whatever validation generated the errors), but that's their problem. We'll provided shotguns and bullets if it's not too hard, they can provide the feet and entertain themselves at will. Regards, Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
newforms issues
I would like to request comments/suggestions about a few patches I have submitted recently for the newforms library that solve some issues that I encountered during the development of some newforms. #3718 - newforms.Form.clean should have access to field errors [1] #3896 - pass value to field specific clean function [2] #4271 - Form should use a copy of data passed to it [3] #4297 - make BaseForm's __errors attribute non-private [4] [1] http://code.djangoproject.com/ticket/3718 [2] http://code.djangoproject.com/ticket/3896 [3] http://code.djangoproject.com/ticket/4271 [4] http://code.djangoproject.com/ticket/4297 Thanks, Gary --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: archive_year generic view and object_list order
On Mon, 2007-05-21 at 15:23 +0200, David Larlet wrote: > Hi, > > I just wonder why the archive_year function returns an object_list > (with make_object_list parameter to True) which is ordered by > date_field. I know that I can use the reverse argument in for loop tag > but I wonder if I'm the only one to have this issue? What order did > you expect by default? I think the Meta one is better... -1. The archive_year function should return things ordered by the year either increasing or decreasing. We picked one direction and you get the other direction by looping in the reversed order. You might be in the lucky situation where your Meta ordering is already based on the date, but that isn't a good assumption in general, so we cannot rely on Meta as a rule. Regards, Malcolm > > David > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: contrib app tests
On Mon, 2007-05-21 at 18:27 -0500, Gary Wilson wrote: > Man, I really need to remember to always use email when posting to these > django lists. Too many of my web posts never show up. And here I > thought the internets was a truck I could just dump stuff on. > > Malcolm Tredinnick wrote: > > On Sat, 2007-05-19 at 00:16 -0500, Gary Wilson wrote: > >> Should we make Django's test runner look for and run all "tests" > >> packages/modules within the Django tree? Or maybe just those in > >> django.contrib? > > > > What's the advantage of looking everywhere? I tend to think this isn't > > worth it because tests for core should all be in one place, for ease of > > maintenance. > > I was thinking that, like the contrib apps, there are other subpackages > in django that could be stand alone packages (with their own tests). > > IMO, it's easier to go looking for tests in the subpackage you are > working on rather than to go hunt for where it is in modeltests or > regression tests. The directory names in modeltests and regressiontests > don't really tell you where in the code to look. I understand your motivation, but it smells like over complicating something that is already very functional and works well in practice. So, at the moment, I'm at most -0 on this. Regards, Malcolm --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: contrib app tests
Man, I really need to remember to always use email when posting to these django lists. Too many of my web posts never show up. And here I thought the internets was a truck I could just dump stuff on. Malcolm Tredinnick wrote: > On Sat, 2007-05-19 at 00:16 -0500, Gary Wilson wrote: >> Should we make Django's test runner look for and run all "tests" >> packages/modules within the Django tree? Or maybe just those in >> django.contrib? > > What's the advantage of looking everywhere? I tend to think this isn't > worth it because tests for core should all be in one place, for ease of > maintenance. I was thinking that, like the contrib apps, there are other subpackages in django that could be stand alone packages (with their own tests). IMO, it's easier to go looking for tests in the subpackage you are working on rather than to go hunt for where it is in modeltests or regression tests. The directory names in modeltests and regressiontests don't really tell you where in the code to look. Also, instead of modeltests, regressiontests, and contrib app tests sharing a common runtests.py namespace, we could make runtests.py accept a module/package name to test. Something like: python runtests.py newforms python runtests.py contrib.markup where the arguments have an implied "django." in front of them. Tests that span multiple packages could stay in the top level "tests" directory. But then how could we run these tests? Maybe we don't allow tests to have an implied "django." in front and running tests would be something like: python runtests.py django.newforms python runtests.py django.contrib.markup python runtests.py tests.modeltests.basic python runtests.py tests.modeltests Or use system path names instead of dots: python runtests.py ../django/newforms python runtests.py ../django/contrib/markup python runtests.py modeltests/basic python runtests.py modeltests which would have the benefit of being able to run tests outside of the django tree. Gary --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Is Mark Warren's Ultimate Wealth Package Worth the Money?
Is Mark Warren's Ultimate Wealth Package Worth the Money? You could go take a college course in marketing or entrepreneurship at your local university or community college and spend thousands of dollars. I took a course called Principles of Marketing. http://2site.com/cnrqev "Legitimate" Online Paid Survey Scams Revealed Part 1 Are you looking for scam-free and legitimate online paid surveys, free membership online paid survey, fact honest paid survey or market online paid research survey? http://2site.com/hqmdca Paypal to RM - Withdraw your money from Paypal to your Bank Account! Since you're reading this, I'm guessing that you guys "desperately" (forgive me if not)need to withdraw the money you all worked (or will work) so hard to earn from paypal? You want to convert your money from Paypal to RM but couldn't find a way to do it? http://2site.com/isfgmb --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
archive_year generic view and object_list order
Hi, I just wonder why the archive_year function returns an object_list (with make_object_list parameter to True) which is ordered by date_field. I know that I can use the reverse argument in for loop tag but I wonder if I'm the only one to have this issue? What order did you expect by default? I think the Meta one is better... David --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Introduction to CRM
Hi All, I just found a link which seems to be quite informative about CRM. Just try the link below to have a look at it. http://www.quazen.com/Business/Management/Introduction-to-CRM.25530 This contains the basics of CRM. I really loved this article. Thanks, Ankur --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: problems serving PDF file from view
On 5/21/07, Curtis <[EMAIL PROTECTED]> wrote: > An alternate solution: > > response = HttpResponse(pdf, "application/pdf") > response['Content-Disposition'] = 'attachment; filename=%s.pdf' % > filename > return response I use a similar approach to output PDF's on our intranet applications and I've got no complaints from users (which use IE although they know they **must not** use it). So I can assume that the Content-Disposition does the trick for me too. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: problems serving PDF file from view
An alternate solution: response = HttpResponse(pdf, "application/pdf") response['Content-Disposition'] = 'attachment; filename=%s.pdf' % filename return response which works for me. I'd be interested to know if it works for others.. Cheers, -Curt On Apr 7, 4:57 pm, "SmileyChris" <[EMAIL PROTECTED]> wrote: > On Apr 6, 7:07 am, "Mike Axiak" <[EMAIL PROTECTED]> wrote: > > > > > Well I can't help but post a more complete solution (;-)) located > > athttp://www.djangosnippets.org/snippets/157/. > > > To be honest, I find Django tries very hard to be compliant with W3C > > (adding things in favor of WCAG, using XHTML when possible, etc). This > > usually isn't a problem because most browser-compatibility things can > > be changed in the template layer. > > > The reason custom middleware had to be written to solve this problem > > is a bug in IE's (mis)use of HTTP. Not HTML (EMCAScript/CSS...), mind > > you, but HTTP. Microsoft has created a page that seems to be a bug- > > report page, not a "this is how we do HTTP" page. AFAIK, this is the > > only example I've seen of browser incompatibilities causing problems > > in the HTTP layer, does anybody else know of any others? > > > Honestly, I am surprised no one else has seen this bug. If they have, > > I am curious what the solutions have been (don't use any of the number > > of Django middleware that use Vary?). > > > Cheers, > > Mike Axiak > > > On Apr 5, 2:35 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > wrote: > > > > Hi All, > > > > I found that Django can not serve PDF files from view, and I feel this > > > is wrong and must be fixed, so I try to raise this topic now. > > > > Problem description: > > > > We've build e-commerce site which sells PDF files as well. For obvious > > > reasons I can not put all our PDF files as static files on media > > > server. > > > > I have also found nice guide and followed it: > > >http://www.djangoproject.com/documentation/outputting_pdf/ > > > > Actual code I've used is this one: > > >http://dpaste.com/7959/ > > > > All worked well, we have installed new site yesterday, and got > > > numerious number of complaints from our users. Tracking down the > > > problem we've found that it is IE specific, well known and mentioned > > > on Microsoft support site: > > > >http://support.microsoft.com/kb/824847/en-us?spid=8722=global > > > > I've asked on IRC, people helped me and pointed out that I should > > > write middleware to fix this problem. Btw, big thanks to 'axiak' from > > > #django IRC by helping to resolve problem in fast manner: > > > >http://dpaste.com/7960/ > > > > Now, I am curious, is this normal that to serve PDF file it is > > > required to write middleware? > > > > Alex > > I'd suggest that this is probably important enough for core addition. > One could whine that it's IEs fault but that doesn't solve the problem. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
