Re: Allow custom "BoundFields" on forms and make BoundField public API

I split the commit in my branch to make the actual changes more visible and moved the example out of the branch into the gist. I will look into the ticket and work out some documentation. Am 08.08.2015 um 13:42 schrieb Tim Graham: > Here is a ticket for making BoundField a public API: >

Re: Future of the development server's auto-reloading

Hi all, I've had experience playing around with watchdog[1] before - I've only ever used it on OS X but it should work cross platform. I've thrown together a rough proof of concept[2] for runserver that uses watchdog to watch for changes/additions/deletions to python files recursively in the same

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

Ok, so I rebased on Tim Graham's refactor and bugfix of ModelForm, and now the API is as follows: `.save()` commits to the database. In `ModelForm`, it returns the associated instance, and in `FormSet`, the list of associated instances. It runs `.apply()` first. `.apply()` just returns the

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

"I like `.apply()`, since it can either suggest that it's applying the form's data to the instance, or applies the validation rules to the form data." I don't think it does either of those things though? I don't find the name intuitive for what it does. I think the purpose of

Re: Future of the development server's auto-reloading

Hello Sam, On 10 août 2015, at 11:34, Sam Cooke wrote: > I've thrown together a rough proof of concept[2] for runserver that uses > watchdog to watch for changes/additions/deletions to python files recursively > in the same directory as manage.py and restarts the server

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

On Monday, 10 August 2015 21:36:27 UTC+10, Tim Graham wrote: > > "I like `.apply()`, since it can either suggest that it's applying the > form's data to the instance, or applies the validation rules to the form > data." > > I don't think it does either of those things though? I don't find the

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

On Monday, 10 August 2015 22:30:51 UTC+10, Javier Candeira wrote: > > Also, is there anywhere I have missed in the documentation that explains > how deprecation works in the project? If we go for such a break with the > existing API, my patch would need to keep the current API working for a >

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

Yes, the idea is that ModelForm.save() method could become (after deprecation finishes): def save(self): """ Save this form's self.instance object and M2M data. Return the model instance. """ if self.errors: raise ValueError( "The %s could not be %s

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

Hi Tim, On 08/10/2015 11:07 AM, Tim Graham wrote: > Yes, the idea is that ModelForm.save() method could become (after > deprecation finishes): > > def save(self): > """ > Save this form's self.instance object and M2M data. Return the model > instance. > """ > if self.errors:

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

Yes, I agree that a documentation change should be sufficient (although I still didn't look at the formsets situation). On Monday, August 10, 2015 at 11:57:19 AM UTC-4, Carl Meyer wrote: > > Hi Tim, > > On 08/10/2015 11:07 AM, Tim Graham wrote: > > Yes, the idea is that ModelForm.save() method

Re: Future of the development server's auto-reloading

Hi Aymeric, I actually spent the PyCon 2015 sprints working on a generic watcher/reloader for Python servers, built on top of watchdog: https://github.com/carljm/wsgiwatcher It should still be considered alpha/prototype code, but I think the approach is promising. It uses a two-process model,

Re: Future of the development server's auto-reloading

In case it is useful as a reference, runserver_plus from django-extensions uses Werkzeug/Watchdog for reloading http://django-extensions.readthedocs.org/en/latest/runserver_plus.html On Monday, August 10, 2015 at 12:15:46 PM UTC-5, Carl Meyer wrote: > > Hi Aymeric, > > I actually spent the

Re: CSRF_FAILURE_VIEW should not be used when DEBUG is False

When users see a CSRF failure, it is almost always because of mistake made by the developer, and it is more useful under those circumstances for the users to see a more specific error message that will help developers rectify the problem. A generic 403 template is very unlikely to be helpful

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

Ok, I'm heading for work now, will give it a spin this evening. Thanks everyone for your comments! J On Tuesday, 11 August 2015 02:07:07 UTC+10, Tim Graham wrote: > > Yes, I agree that a documentation change should be sufficient (although I > still didn't look at the formsets situation). > >