Ticket #15860: modelform.is_valid() and modelform.errors fail to anticipate database integrity errors, allows exceptions to reach the user
I hope it's OK to copy the body of the ticket here, even if it is redundant, in order to spur discussion. I'm willing to work on a patch if there is a consensus as to the proper solution... modelform.is_valid() fails to anticipate database integrity errors when those errors involve any fields that are not part of that form itself. Technically, this is because the modelform.validate_unique() method uses the modelform._get_validation_exclusions() method (which lists any model fields that are not in the form itself) to define the exclusions for the call that is made to the ORM object's validate_unique() method (see here: http://code.djangoproject.com/browser/django/trunk/django/forms/models.py#L339). In practical terms this is a bad thing because, in a variety of circumstances, modelform.is_valid() returning False is the only thing that will prevent modelform.save() from being called, and modelform.save() will, in such a case, raise an IntegretyError that will not be caught. In my opinion, modelform.is_valid() should always report that a form is NOT valid if it is certain that a call to save() will raise an exception. The implementation problem here is either: 1. that modelform._get_validation_exclusions() is too liberal in its exclusions, 2. that those liberal exclusions should not be passed at all to instance.validate_unique(), or 3. that the implementation of instance.validate_unique() is using those exclusions incorrectly. It seems that the original logic was that model fields that are not part of the form should be excluded from the decision whether to mark a form as invalid. But a form *is* invalid if it cannot be saved to the database, regardless of the reason. Now, an argument can be made to the effect that model fields which are not form fields are not the concern of the form and SHOULD cause an IntegrityError to be raised, but that argument is not entirely relevant: instance.validate_unique() excludes all validations that reference *any* of the excluded fields, even if multiple-field constraints include fields that are, in fact, part of the form. So, if the user changes a field on a form that combines with another, hidden value to violate a constraint, the user will see a 404 or exception page, instead of a meaningful error message explaining how they can fix their mistake. For me, this is a problem in the case of "unique_together" fields, where one field is editable on the form, and the other is set at record creation time or in some other programmatic way. It is possible, even likely, that a uniqueness constraint will be violated by a user changing the editable field, causing in the current implementation an IntegrityError to rise to the top of the stack, directly impacting the user. Instead, the user should be told that the data they entered is not sufficiently unique. -- 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: proposal Meta.exclude in Form
Le 20 avr. 2011 à 05:57, Constantine a écrit : > FormModel have exclude attribute in Meta, but simple Form doesnt: > example usage: > > i need base form for editing with many fields, and derived form for > object creation with subset of fields and so i want to exclude > unnecessary fields Actually, I don't understand. If you need object creation, ModelForm is the way to go. You could also take it the other way. Base form should be the one with the smallest field set. Regards, Xavier. -- 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: proposal Meta.exclude in Form
generally it's lack of Meta subclass in simple form, in which we can configure fields order, exclusion of some fields etc. Now i should override __init__ method, its not so declarative way as in modelform -- 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.
proposal Meta.exclude in Form
FormModel have exclude attribute in Meta, but simple Form doesnt: example usage: i need base form for editing with many fields, and derived form for object creation with subset of fields and so i want to exclude unnecessary fields -- 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: Is using version 2 of the pickle protocol in {DB,FileBased}Cache
Ah, this does sound like a pretty nasty issue with our code then. Unfortunately, the test suite doesn't get run as often as it should with the various cache backends enabled, and I imagine that may be how this cropped up. There have been a number of similar bugs in the past - caching is hard! I'd appreciate it if you could open a ticket for this and reference the mailing list discussion. If you could set the owner to me (PaulM), I'll work on it when I get a chance. Thanks for taking the time to track down how this is happening. -Paul -- 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: RFC: new backports policy
On 04/19/2011 05:24 PM, Luke Plant wrote: > Another issue with regards to backporting bug fixes that Jacob didn't > mention is the fact that bug fixes often introduce subtle regressions > and backwards incompatibilities. > > Personally, I find that backporting a fix very often takes only a > minute, by appropriate use of DVCS features (e.g. hg transplant) and > some scripting. (This doesn't include the time for running tests again, > and doesn't include cases where the merge fails or the patch has to be > effectively re-written). However, the problems caused by introducing > these regressions onto supposedly stable branches can be much more time > consuming and tricky. > > By keeping backporting of bugs down to a minimum, we avoid these > problems, and help keep our stable branch genuinely stable. Not > introducing regressions is much more important than fixing existing > bugs, since most people will have worked around existing bugs where > necessary for their needs anyway. +1 to all of this. IMO the bigger issue is the regressions that inevitably get introduced when we backport all bugfixes, not the extra committer time to do backports (which I also agree I haven't found problematic). Carl -- 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: RFC: new backports policy
Another issue with regards to backporting bug fixes that Jacob didn't mention is the fact that bug fixes often introduce subtle regressions and backwards incompatibilities. Personally, I find that backporting a fix very often takes only a minute, by appropriate use of DVCS features (e.g. hg transplant) and some scripting. (This doesn't include the time for running tests again, and doesn't include cases where the merge fails or the patch has to be effectively re-written). However, the problems caused by introducing these regressions onto supposedly stable branches can be much more time consuming and tricky. By keeping backporting of bugs down to a minimum, we avoid these problems, and help keep our stable branch genuinely stable. Not introducing regressions is much more important than fixing existing bugs, since most people will have worked around existing bugs where necessary for their needs anyway. Regards, Luke -- "In my opinion, we don't devote nearly enough scientific research to finding a cure for jerks." (Calvin and Hobbes) Luke Plant || http://lukeplant.me.uk/ -- 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: RFC: new backports policy
On 04/19/2011 02:35 PM, Daniel Moisset wrote: I'm using 1.3 in production and there's a bugfix I really want, so I do the backport (and write the code, tests, docs). If I submit this to the issue tracker, is there a chance my patch will get into the next minor release, or you won't even consider it? Even with an accepted (or even ready-for-checkin) ticket containing all what's needed committers have some non-trivial amount of work to do. As I understand intention of the new policy it's this work that they want to decrease. In such situation at my company we just patch our internal Django package. In fact we often patch an immediate problem locally first and only then bring the patch to discussion upstream. Much less pressure for everyone. I think you should either live with official stable releases or be ready to maintain your own if you choose to live on trunk. -- 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: RFC: new backports policy
On Tue, Apr 19, 2011 at 4:22 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > > > The core team has come to a rough consensus and we're planning to drop > this backport-everything policy. Instead, we'll only backport critical > patches. That is, we'd only backport patches for: > > * Security issues. > * Data-loss bugs. > * Crashing bugs. > * Major functionality bugs in newly-introduced features. > > In other words, we'd basically only backport bugs that would have > prevented a release in the first place. Is this a policy against backporting fixes by default, or against the backports themselves? Let me put it in another way with an example: you don't want to do the backport, and it's your policy, and it sounds like a good idea. But I'm using 1.3 in production and there's a bugfix I really want, so I do the backport (and write the code, tests, docs). If I submit this to the issue tracker, is there a chance my patch will get into the next minor release, or you won't even consider it? The answer for this should be included in the documentation, it's useful for end-users and also for people reviewing patches Regards, D. -- 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: RFC: new backports policy
Perhaps augment the new policy by stating that contributed backports for bugs that are left out by this change will be favorably looked upon, and committed to the branch unless there is a good reason no to commit them. This still achieves the goal of making the routine bugfix commit cycle faster, but allows people that depend on stable releases to "scratch their itch", backport the important bugfixes, and get them as part of a "blessed" stable branch release. On Tue, 19 Apr 2011 22:22:26 +0300, Jacob Kaplan-Moss wrote: Hi folks -- Over the past few weeks, the core development team have been discussing how we can streamline our process to get more work done quicker. It's pretty clear that the bulk of the community wishes Django could move forward a bit faster [1], and we'd like to be able to deliver more awesomeness in less time. Ultimately, the goal will be to put out releases quicker, hit our deadlines more accurately, and be able to respond to community suggestions and patches in a more timely manner. [1] This isn't unique to Django, of course; almost every open source project wishes they could release more features more quickly. One way that we'd like to improve our speed is by modifying our existing backport policy. To refresh your memories, right now we backport any non-feature-containing patches to the previous release. So if we fix a bug on trunk, we backport the bug fix to the 1.3.X branch, where it would become part of the 1.3.1 release. This is a fair bit of work: it basically means we have to fix each bug twice. The core team has come to a rough consensus and we're planning to drop this backport-everything policy. Instead, we'll only backport critical patches. That is, we'd only backport patches for: * Security issues. * Data-loss bugs. * Crashing bugs. * Major functionality bugs in newly-introduced features. In other words, we'd basically only backport bugs that would have prevented a release in the first place. Practically, this means that if there's a minor bug in 1.3 -- for example, #15795, a bug with the representation of RegexURLPattern -- the fix *will not* be applied to the 1.3.X branch, and thus no 1.3.* release will contain the fix, even if it's fixed in trunk. To get the fix for these bugs, users will have to upgrade to 1.4. The upside, of course, is that bug fixes will be quicker to apply, so we can fix more bugs, so we can get that 1.4 release out sooner [2]. Additionally, this'll give users more of an incentive to upgrade to the latest-and-greatest. This means that they get new features, and we (the development community) get to focus more clearly on moving forward, not maintaining older releases. [2] Look for a proposed release date soon. Spoiler alert: it's sooner than you think. We'd like to make this change effective immediately, but we also don't want to just issue this change by fiat. So we're requesting comments and feedback on this change. Do you like the idea? Why or why not? Will this policy make it more likely you'll contribute? Less likely? 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-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: RFC: new backports policy
On 19 avr. 2011, at 21:22, Jacob Kaplan-Moss wrote: > We'd like to make this change effective immediately, but we also don't > want to just issue this change by fiat. So we're requesting comments > and feedback on this change. Do you like the idea? Why or why not? > Will this policy make it more likely you'll contribute? Less likely? Hello Jacob, I thought that the work required to backport a patch was relatively low compared to the work required to understand a ticket and review proposed changes. Not being a core developer, I'll take your word that it is "a fair bit of work". As someone who manages development projects on a 1-2 year scale, I am +1 on this new policy. At some point, these projects stabilize and development turns into maintenance. We want to use the most recent release of Django at that point, and then stay on that branch: - more frequent releases means we could use releases during the "build" (rather than trunk) and still get fixes within a decent timeframe; - less changes in maintenance branches means it would be safer to update Django during the "run". As someone who hacks on Django, the main factor preventing me from contributing more is the relatively low chance that someone will review or commit my patches. Reviewing patches written by others hits the same problem: more often than not, I upload an improved version, thus I can not mark the ticket as RFC. The backlog of unreviewing and uncommitted patches is quite discouraging. If this new policy helps core developers to review and commit patches faster, I'm also +1. Best regards, -- Aymeric Augustin. -- 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: RFC: new backports policy
On Tue, Apr 19, 2011 at 3:22 PM, Jacob Kaplan-Moss wrote: > Hi folks -- > > Over the past few weeks, the core development team have been > discussing how we can streamline our process to get more work done > quicker. It's pretty clear that the bulk of the community wishes > Django could move forward a bit faster [1], and we'd like to be able > to deliver more awesomeness in less time. Ultimately, the goal will be > to put out releases quicker, hit our deadlines more accurately, and be > able to respond to community suggestions and patches in a more timely > manner. > >[1] This isn't unique to Django, of course; almost every open > source project wishes they could release more features more quickly. > > One way that we'd like to improve our speed is by modifying our > existing backport policy. To refresh your memories, right now we > backport any non-feature-containing patches to the previous release. > So if we fix a bug on trunk, we backport the bug fix to the 1.3.X > branch, where it would become part of the 1.3.1 release. This is a > fair bit of work: it basically means we have to fix each bug twice. > > The core team has come to a rough consensus and we're planning to drop > this backport-everything policy. Instead, we'll only backport critical > patches. That is, we'd only backport patches for: > > * Security issues. > * Data-loss bugs. > * Crashing bugs. > * Major functionality bugs in newly-introduced features. > > In other words, we'd basically only backport bugs that would have > prevented a release in the first place. > > Practically, this means that if there's a minor bug in 1.3 -- for > example, #15795, a bug with the representation of RegexURLPattern -- > the fix *will not* be applied to the 1.3.X branch, and thus no 1.3.* > release will contain the fix, even if it's fixed in trunk. To get the > fix for these bugs, users will have to upgrade to 1.4. > > The upside, of course, is that bug fixes will be quicker to apply, so > we can fix more bugs, so we can get that 1.4 release out sooner [2]. > Additionally, this'll give users more of an incentive to upgrade to > the latest-and-greatest. This means that they get new features, and we > (the development community) get to focus more clearly on moving > forward, not maintaining older releases. > >[2] Look for a proposed release date soon. Spoiler alert: it's > sooner than you think. > > We'd like to make this change effective immediately, but we also don't > want to just issue this change by fiat. So we're requesting comments > and feedback on this change. Do you like the idea? Why or why not? > Will this policy make it more likely you'll contribute? Less likely? > > Thanks! > > Jacob Hi All - In general I prefer to think about this the other way around: If we have a most current stable release of product X, it makes sense to fix any bugs that come up in that product. For the sake of the next release, assuming the bug was not fixed or made obsolete by some other change, it then also makes sense to /forward port/ that bug fix to the current (unstable) development trunk. Calling it "forward porting" rather than "back porting" makes it sound better, too. :-) This workflow fits quite well if you're using one of the DVCS mirrors of the Django repository, as it can be as easy as merging the latest release branch into default/master on a regular basis. There is obviously more to the story (running tests, dealing with the occasional merge conflict), but to me, it seems like the majority of the work is in fixing the original bug in the first place, not in applying that same fix to another branch of the code. If my assumption is true, we might as well apply the fix in both places once it has been made. Being a non-core-committer perhaps I don't fully understand the additional work involved, but I do appreciate the focus on stability in Django's releases and I'd rather be forced to upgrade due to new features that I want, rather than some silly bug that'll never be fixed -- especially if a stable release that includes the fix I need is not even available yet. In other words, if a bug in a product has been fixed, it seems odd to me that no stable release of the product will include that fix. What if the window for bug fixes was time boxed, so that bug fixes would be back/forward ported as usual up until 1-2 months prior to a new stable release (perhaps coinciding with the first release candidate)? This way at least we have some semblance of a stable release destined to include all bug fixes at all points in time, and the actual window in which a bug fix might not make it into the current official stable release is reduced. Just my 2 cents - hope that helps! Tobias -- Tobias McNulty, Managing Partner Caktus Consulting Group, LLC http://www.caktusgroup.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 un
RFC: new backports policy
Hi folks -- Over the past few weeks, the core development team have been discussing how we can streamline our process to get more work done quicker. It's pretty clear that the bulk of the community wishes Django could move forward a bit faster [1], and we'd like to be able to deliver more awesomeness in less time. Ultimately, the goal will be to put out releases quicker, hit our deadlines more accurately, and be able to respond to community suggestions and patches in a more timely manner. [1] This isn't unique to Django, of course; almost every open source project wishes they could release more features more quickly. One way that we'd like to improve our speed is by modifying our existing backport policy. To refresh your memories, right now we backport any non-feature-containing patches to the previous release. So if we fix a bug on trunk, we backport the bug fix to the 1.3.X branch, where it would become part of the 1.3.1 release. This is a fair bit of work: it basically means we have to fix each bug twice. The core team has come to a rough consensus and we're planning to drop this backport-everything policy. Instead, we'll only backport critical patches. That is, we'd only backport patches for: * Security issues. * Data-loss bugs. * Crashing bugs. * Major functionality bugs in newly-introduced features. In other words, we'd basically only backport bugs that would have prevented a release in the first place. Practically, this means that if there's a minor bug in 1.3 -- for example, #15795, a bug with the representation of RegexURLPattern -- the fix *will not* be applied to the 1.3.X branch, and thus no 1.3.* release will contain the fix, even if it's fixed in trunk. To get the fix for these bugs, users will have to upgrade to 1.4. The upside, of course, is that bug fixes will be quicker to apply, so we can fix more bugs, so we can get that 1.4 release out sooner [2]. Additionally, this'll give users more of an incentive to upgrade to the latest-and-greatest. This means that they get new features, and we (the development community) get to focus more clearly on moving forward, not maintaining older releases. [2] Look for a proposed release date soon. Spoiler alert: it's sooner than you think. We'd like to make this change effective immediately, but we also don't want to just issue this change by fiat. So we're requesting comments and feedback on this change. Do you like the idea? Why or why not? Will this policy make it more likely you'll contribute? Less likely? 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-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: Admin DateTimeShortcuts performance (feature request / improvement suggestion)
Just wanted to point you to the ticket I've opened for this topic: http://code.djangoproject.com/ticket/15231 Since the patch is in for two months now, I thought it was ok to kindly ask if someone was willing to do a review on this. Happy about every review and improvement suggestion! Thanks and regards, Fabian 2011/1/28 Fabian Büchler > Thanks for the super fast reply, Russ! > > the way you put it makes sense to me, so I guess I'm going to start over > with replacing just the DateTimeShortcuts script and trying to use that from > within the inlines script. > > Regards, > Fabian > > > 2011/1/28 Russell Keith-Magee > >> On Fri, Jan 28, 2011 at 10:18 PM, Fabian Büchler >> wrote: >> > Hello Django developers, >> > >> > as this is my first post here, let me shortly introduce myself: >> > I'm Fabian Büchler, webdeveloper from Vienna, Austria; relatively new to >> > Django and just thinking about hacking on Django itsself ... >> > I've read all your contribution guidelines and I believe this to be the >> > correct place for my concern - please correct me if I'm wrong. >> >> You've found the right place - and welcome! >> >> > I have a suggestion for improvement to the Django admin, namely the >> > DateTimeShortcuts - especially in combination with model inlines. >> > >> > The big picture >> > In a project I'm working on an event management tool for the Vienna >> tourist >> > board and one of our models is heavily date based: >> > Event 1> forms). >> > >> > Each EventDate has two date fields and two time fields, that means four >> > date/time pickers per inline row. >> > When adding new rows using the "Add new row" link, this is already quite >> > slow. The more inline rows are on the page, the slower it gets. >> > >> > In addition to that, I've built a generator tool for these inlines which >> > generates EventDates by requested patterns (per weekday, for a certain >> date >> > range,...). >> > When generating more than a hand full of inline rows at a time, the >> browser >> > slows down to a halt - continuous JS timeouts included. >> > >> > All this happens on multiple, relatively new computers (all OSes), in >> the >> > newest browsers (FF3.6, FF4b10,...). >> > After some JS profiling I found, that the problem seems to be burried >> within >> > the reinitialization of all .datetimeshortcuts every time a new inline >> row >> > is being added. >> > The processing of that takes about 95% of the overall JavaScript >> processing >> > time. >> > >> > My improvement suggestion >> > As a solution I would suggest to rewrite the complete >> DateTimeShortcuts.js >> > using jQuery (it is not jQuery based at all atm.), especially jQuery's >> new >> > (1.4.2) event delegation functionality [0] to improve performance. With >> > event delegation, no reinitialization of newly added .datetimeshortcuts >> > elements would be necessary at all. >> > As an addition, I think it would make sense to integrate the jQuery UI >> > datepicker (maybe with a timepicker extension [1]) instead of the >> existing >> > one, because that might resolve some problems, as with the datepicker >> > opening outside of the viewport when the calendar icon is too far on the >> > right side of the screen. >> > >> > I am willing to try to implement this myself (and, of course, provide >> any >> > outcomes to the community). >> > But before starting, I first wanted to hear your opinions to my >> suggestion >> > and - if accepted - any pointers to how you would like this to be >> > implemented. >> >> For some background -- Django's admin started as a hand-crafted >> Javascript solution -- mostly because it predates the existence of >> jQuery as a widely accpted javascript framework. We only added jQuery >> to the admin around a year ago. >> >> As a result, there is an admin javascript cleanup needed. Updating >> date/time handling is part of that. >> >> The best way to approach this is to Just Do It. Pick some specific >> aspect of the Javascript where you think a jQuery-based cleanup is >> called for, prepare a patch, then open a ticket and upload your patch >> to that ticket. >> >> Try to constrain the scope of your changes if you can. Don't just drop >> a "I've fixed all your Javascript" patch on our laps -- if you start >> smaller, it's a lot easier for us to give feedback. >> >> As for using JQueryUI -- we don't currently have that dependency, so >> you'll have to make your case for why we should add the new >> dependency. If you can show a sample implementation that saves X% of >> code, or is Y% faster, or has new features ABC, that will go a long >> way to making your case. >> >> So - thanks for offering to help out! Can't wait to see the >> improvements you can make. >> >> 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
Re: Right way to do formfield-less fields?
On 04/19/2011 09:44 AM, Jonas H. wrote: > On 04/10/2011 03:14 PM, Jonas H. wrote: >> What's the preferred way to do a custom model field that has no >> corresponding formfield? Intuitively, I'd say raise a >> NotImplementedError, but that would make the whole model unusable in the >> admin even if that field is excluded from being displayed. I haven't tried this, but based on the implementation of `fields_for_model` it looks to me like returning None might work (it would cause that field to not be included in the SortedDict returned by fields_for_model, so you wouldn't even need to list that field in `exclude` - in fact, you couldn't or it would fail validation). >> So, are fields without a formfield possible already? If yes, how to do >> it? If not, would you accept a patch that makes the `ModelAdmin.exclude` >> attribute validation not call into `Field.formfield`? In theory, yes, although a brief look at the relevant code doesn't suggest any obvious clean fixes to my mind. Carl -- 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: Is using version 2 of the pickle protocol in {DB,FileBased}Cache
Paul McMillan writes: > Yes, SimpleCookie is known to be an unpickleable class. We shouldn't > be directly pickling it anywhere in Django. In your code, you should > probably turn the cookie into a string before caching it. I'm not > clear if the bug you're experiencing is happening in Django's code or > something your application is doing directly with SimpleCookie. [snip] > I think that your provided test case is trying to do something that is > explicitly not supported, but I'm unclear on whether or not there is > an issue in Django-provided code. Could you provide a little more > information? Hi Paul, I am not trying to pickle SimpleCookie directly -- in fact, I enabled the cache middlewares in settings.py and then set CACHE_BACKEND to 'file:///some/directory'. I then had a view with no specific cache decorators, but since the session backend is also on it added the `Vary: Cookie' header. After that, I started noticing that a login page including the `csrf_token' tag started repeating the token when I used curl to access it without providing any cookies or login credentials. And after the first time I accessed it, the Set-Cookie header started misbehaving like it did in the test case I attached -- instead of looking like Set-Cookie: foo=bar; other-parameters; it was looking like Set-Cookie: foo="Set-Cookie: foo=bar; other-parameters;" and the value in the csrf tag was being expanded to something along the lines of "Set-Cookie: foo=bar; other-parameters;", so validation failed later. Some investigation led me to find the problem in the cache backend I was using, as the cookies inside the cached HttpResponse were being serialized incorrectly and later picked by FetchFromCacheMiddleware. -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi -- 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: Right way to do formfield-less fields?
On 04/10/2011 03:14 PM, Jonas H. wrote: Hello! What's the preferred way to do a custom model field that has no corresponding formfield? Intuitively, I'd say raise a NotImplementedError, but that would make the whole model unusable in the admin even if that field is excluded from being displayed. That's because excluding a field from the admin display does not mean `Field.formfield(...)` is left alone, a call into `formfield` happens during validation checks (`check_formfield` in admin/validation.py). So, are fields without a formfield possible already? If yes, how to do it? If not, would you accept a patch that makes the `ModelAdmin.exclude` attribute validation not call into `Field.formfield`? Cheers, Jonas *push* -- 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: Fixing makemessages for Javascript
Hi Lukasz,
It does not yet generate .po files. While I haven't yet had any plans
for doing this, it's not really complex at all to make this possible
through the preprocessor.
What is currently does, is parsing and processing templates and
external css/js files. It does a lot of optimizations in order to gain
better performance at runtime, and one of the optimizations is to
preprocess all the translations.
Currently {% trans %} and {% blocktrans %} are preprocessed, even with
support for variables and {% plural %}. HTML, javascript and CSS are
also parsed, so now it's not too much work to preprocess gettext() in
javascript files as well.
The output is a 'cache' directory where the processed templates are
stored (one subdir for each language), and a cache directory for the
media/static files.
This would make using gettext() for internal javascript files instead
of the ugly {% trans %} within quotes have no more disadvantages.
And while everything is processed, it's rather easy log all the
strings which are to be translated on the way.
Cheers,
Jonathan
On 19 avr, 15:50, Łukasz Rekucki wrote:
> On 19 April 2011 15:35, Jonathan Slenders wrote:
>
>
>
> > Basically, when this works, the i18n catalog for javascript is no
> > longer required, even for external files.
> >https://github.com/citylive/django-template-preprocessor
>
> Could you elaborate on that ? How does your application help me handle
> client-side translations ?
>
> --
> Łukasz Rekucki
--
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: Fixing makemessages for Javascript
On 19 April 2011 15:35, Jonathan Slenders wrote: > > Basically, when this works, the i18n catalog for javascript is no > longer required, even for external files. > https://github.com/citylive/django-template-preprocessor > Could you elaborate on that ? How does your application help me handle client-side translations ? -- Łukasz Rekucki -- 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: Fixing makemessages for Javascript
A related question.
How should we thread escape characters when the msgid is generated?
Is the escaping backslash assumed to be part of the translation?
And is this behaviour consistent between Babel and the current parser?
gettext("xy\"zzy 3");
In my opinion, we should completely unescape the gettext string before
doing the translation, and escape it again afterwards.
I'm asking this because I'm going to implement gettext preprocessing
in the template preprocessor and I'd like all implementations to be
compatible.
Basically, when this works, the i18n catalog for javascript is no
longer required, even for external files.
https://github.com/citylive/django-template-preprocessor
cheers,
Jonathan
On 18 avr, 00:14, Ned Batchelder wrote:
> On 4/15/2011 12:40 PM, Russell Keith-Magee wrote:
>
>
>
>
>
>
>
> > On Fri, Apr 15, 2011 at 9:25 PM, Ned Batchelder
> > wrote:
> >> On 4/14/2011 11:40 PM, Russell Keith-Magee wrote:
>
> >> Keep in mind that the proposal is not to include Babel, but to depend on it
> >> as a prerequisite, which means we are stuck in the same situation we are
> >> with gettext: it can change independently of Django, and new versions can
> >> introduce new bad behavior. That's one of the reasons we have a bad
> >> problem
> >> today: gettext changed from 0.17 to 0.18, and exacerbated the hack.
> > This is true. However, what you're proposing is, IMHO, a slightly
> > worse situation.
>
> > Babel is a self contained tool. Assuming it work as advertised (and
> > I'll grant that is a big and important assumption), it is a self
> > contained body of code. It is a dependency, but as long as it
> > continues to work as advertised, we're fine. We're only dealing with
> > it's advertised interface, and working with that interface in the way
> > it was intended to be worked with.
>
> > On the other hand, gettext is also a dependency, and gettext can also
> > change between releases -- but we're not using it as intended. We're
> > bending the Perl parser (or, in your case, the C parser) in strange
> > and unusual ways to do something it wasn't originally intended to do.
> > Something completely innocuous can change in gettext, and the
> > follow-on effect to us can be huge because we've built our castle on
> > an unstable foundation.
>
> I'm not much concerned that the C parsing in gettext will change
> significantly, but I take your point, it certainly could change behind
> our backs and we could be broken again.
>
>
>
>
>
>
>
>
>
> > The maintenance issue is the critical part here. My hesitation isn't
> > just to do with the suitability of your code *right now*. It's to do
> > with the fact that once we adopt the code into trunk, we are to
> > agreeing to maintain it. Bits don't rot, but gettext has already
> > demonstrated that it changes between versions, so it's reasonable to
> > assume that when gettext 0.19 is released (whenever that happens),
> > we'll need to make changes to our Javascript parser. By taking on the
> > lexer, we're absorbing into Django a whole bunch of project
> > responsibility that frankly, I'd rather we didn't have.
>
> >> Babel
> >> has the advantage that it is pure Python, so it is both more installable
> >> than gettext, and is more readable for us. It also has the advantage that
> >> it isn't based on a hack, but that doesn't mean it performs flawlessly.
>
> >>> If the proposed patch was leaning on a well established lexer, or was
> >>> a simple configuration change (i.e., "treat it as C, not Perl") that
> >>> could be quickly demonstrated to fix a bunch of problems without
> >>> introducing any obvious new problems, I'd be all in favor of it as a
> >>> temporary solution. But that's not what is on the table -- it's a
> >>> complex body of code that we're proposing to evaluate, introduce,
> >>> maintain, and potentially deprecate very quickly.
>
> >> While the patch I've submitted is certainly larger than a configuration
> >> change, and is not a well-established lexer, I have "quickly demonstrated
> >> that it fixes a bunch of problems without introducing any obvious new
> >> problems", or at least, no one has come forward with a new problem. I've
> >> paid a bounty on Stack Overflow for people to find problems in the lexer
> >> itself, which they have done, and those problems have been fixed.
> > That sort of thing evidence certainly works in your favor -- I wasn't
> > aware that this sort of testing had taken place.
>
> >>> I'm happy to be proven wrong on any of the points mentioned here --
> >>> for example, if someone can provide some mechanism that independently
> >>> demonstrates the robustness of the Javascript lexer, or evidence that
> >>> the risk of regressions is low. However, absent of such evidence, I'm
> >>> inclined to side with Jannis and concentrate our efforts on Babel --
> >>> especially if, as Jannis suggests, a Babel-based solution isn't that
> >>> much work and could be knocked off easily with a short concentrated
> >>> effort.
> >>
Re: #14891, a.k.a. "related managers don't work how we claim they do"
Am 19.04.2011 um 00:03 schrieb Carl Meyer: > Hi Johannes, > > On 04/18/2011 01:45 PM, Johannes Dollinger wrote: >> Deprecate `use_for_related_fields` and always use the default manager >> for related managers. Then add the possibility to specify custom >> mangers for individual relations: >> >> ForeignKey(Foo, related_manager=RSpecialManager) ManyToManyField(Foo, >> manager=SpecialManger, related_manager= RSpecialManager) >> >> More fine grained control would especially be useful for subclasses >> of ForeignKey and ManyToManyField fields. It comes at the expense of >> verbosity, but it appears to be a rarely used feature (given that the >> bug was discovered only now). And thus, explicitness might actually >> be a good idea. > > Do you have real-world use-cases in mind that require per-relation > manager configuration? I can't think of any uses I've run across that > weren't workable with a single default manager used by all relations. The only time I used a custom manager for a relationship was for a TagField – making .add() accept bare strings. It's been more useful for me to use a custom descriptor, e.g. this TagField's descriptor delegates __set__ to an .assign() method on the manager. Another use-case for custom descriptors was an experimental ListField, where the related manager behaves like a list of related objects (e.g. supports slicing, iteration, assignment). I don't think these examples necessarily need a public API, although it'd be nice to reduce the the dependencies on internal API in my code. Let me turn the question around: do you have real-world use-case that benefits from use_for_related_fields? Especially one that cannot be solved more cleanly with custom queryset methods? -- 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.
