Re: Form/view for ManyToMany relationship

Le 05/03/2011 00:01, kgardenia42 a écrit :

Thanks.  This is pretty close to what I'm doing.  However, I'd like to not have to write all the associated boiler-plate (i.e. I have to figure out if any film/actor relationships have been deleted since the last save and explicitly write code to remove those and so on).  

Well, you can delete all related filmrole then save the new set, but I don't know if it's really an "efficient" way to handle that.

Out of topic: I have an obsession about providing "undo" ability as much as possible and showing changes before "committing" may help user too.

It seems that I would even have this problem if I added a simple "auto now" date/time field to my relationship class, which seems a bit restrictive.  

Using a "timestamp" allows you to never edit / delete a entry: you just add new ones and work on last "timestamped" related entries for current data.

I use this myself intensively because I _need_ to provide audit tables. I use in this case two apps: one "normal" (without timestamps) and an "audit" app that is dependant of the "normal" app. I use two distinct tables (databases, actually) and performances are ok in my context (including about 30,000 modifications by batch at once at least once a week).

ModelForm already knows how to do all that (it can do so when the relationship class is implicitly created) so what I imagined was *somewhere* I could override a method and provide the defaults for the missing fields and then it would all  just works magically.    Does this make sense?  Can anyone give me any pointers to how I might do this (I'm keen to learn the "right way" to do things).  

You can provide defaults in your Model. (I don't know if it's really required, but can use constants in these case: this allows to retrieve these entries without introducing more hardcoded values in your code)

I'm happy to hack this myself and contribute something if someone could give me some pointers of where I should start or where something like this ought to live.  

I don't feel comfortable with your way to handle this relashionship, but it may be appropriate in a "wizard" approach. Maybe some form related project can appreciate your efforts.

Regards,