Re: Move form_for_instance and form_for_model into django.db.models.Model?

2007-07-13 Thread Peter Nixon
On Fri 13 Jul 2007, Todd O'Bryan wrote: > On Thu, 2007-07-12 at 15:40 -0500, Adrian Holovaty wrote: > > On 7/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > > > Is there a good reason not to do something like the following in > > > django.db.models.Model? > > > > > > def form(self): > > >

Re: How decoupled should forms and models be (was: Re: Move form_for_instance and form_for_model into django.db.models.Model?)

2007-07-12 Thread Malcolm Tredinnick
On Fri, 2007-07-13 at 01:31 -0400, Todd O'Bryan wrote: > On Fri, 2007-07-13 at 14:43 +1000, Malcolm Tredinnick wrote: > > > I'm -1 one on this for pretty much the same reasons as Adrian. It's just > > not that big a deal even for people who want to work the way you do. > > I should have

Re: How decoupled should forms and models be (was: Re: Move form_for_instance and form_for_model into django.db.models.Model?)

2007-07-12 Thread James Bennett
On 7/13/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > My question for the rest of the second message was a question of how > much separation between forms and models there should be. For me the > validation issue is key. We currently don't have any standard way to > programmatically validate

Re: Move form_for_instance and form_for_model into django.db.models.Model?

2007-07-12 Thread Malcolm Tredinnick
On Thu, 2007-07-12 at 18:21 -0400, Todd O'Bryan wrote: > form_for_instance and form_for_model are great, but if you have to tweak > the form in any way (say you want to use a non-default widget for one of > the data fields) and want to use it more than once, you're reduced to > defining a new

Re: Move form_for_instance and form_for_model into django.db.models.Model?

2007-07-12 Thread Collin Grady
This doesn't seem a far step from the model fields being able to return appropriate form fields, which they already do, so there's some tie-in already :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django

Re: Move form_for_instance and form_for_model into django.db.models.Model?

2007-07-12 Thread Todd O'Bryan
On Thu, 2007-07-12 at 15:40 -0500, Adrian Holovaty wrote: > On 7/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > > Is there a good reason not to do something like the following in > > django.db.models.Model? > > > > def form(self): > > return form_for_instance(self) > > > > @classmethod > >

Re: Move form_for_instance and form_for_model into django.db.models.Model?

2007-07-12 Thread Adrian Holovaty
On 7/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > Is there a good reason not to do something like the following in > django.db.models.Model? > > def form(self): > return form_for_instance(self) > > @classmethod > def form(cls): > return form_for_model(cls) Yes -- the good reasons

Re: Move form_for_instance and form_for_model into django.db.models.Model?

2007-07-12 Thread Marty Alchin
On 7/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > As I was writing this, I realized that you can't do this in Python > because you can't overload function names, but surely somebody smarter > than me can figure out a clever way that model_instance.form() and > ModelClass.form() would both do

Move form_for_instance and form_for_model into django.db.models.Model?

2007-07-12 Thread Todd O'Bryan
Is there a good reason not to do something like the following in django.db.models.Model? def form(self): return form_for_instance(self) @classmethod def form(cls): return form_for_model(cls) As I was writing this, I realized that you can't do this in Python because you can't overload