> > def save(self):
> > if not self.id:
> > super(Entry, self).save() # to get the Id
> > self.divisions.add(self.mainDivision)
> > super(Entry, self).save() # annoying double save...
> >
> > If I apply 'save' to all instances of Entry in the shell, the
> > relationship is added appropriately.
> > However, if I modify or create an entry in the web admin interface,
> > the relationship does not show up in divisions. I know 'save' is
> > called (because I get stack traces if I raise something there), but
> > the 'add' seems to fail in that case.
> > Any clue? I am not sure this is a bug, but it sure puzzles me...
>
> Related objects are saved after the main object saves in the standard
> AddManipulator (django.db.models.manipulators) that the admin interface
> is using. That could be causing some problems. We're not going to be
> changing anything there, though, since the newforms-admin branch is
> destined to replace that portion of the admin behaviour with the
> manipulator-less system in newforms.
I ran into this exact situation just a few days ago. The "easy"
solution I came up with after some help from this fine group of people
was to to keep my save() extension as-is so that calls from the shell
or other non-admin locations would work as expected.
To get the desired behavior from the admin pages, I used JavaScript to
add an onsubmit handler to the form that would add the main division
to the other divisions. That way when django processes the form it
never knows the difference. Of course, you'll still need to enforce
that rule in your save() by doing some validity checks.
If you choose this route, you should be aware of a couple of pitfalls:
The first is that manipulation of the form differs depending on
whether or not you are using the 'filter_interface' parameter your
column type. If you are then you need to add an option to the select
field with an id of "id_colname_to". This is not going to be obvious
by looking at the page source.
If you are not using the filter interface, then you'll be concerned
with the "id_colnam" select node.
In either case, it may not be enough to simply iterate through the
option nodes and check which one to select. The option you need to
select may not be there, as would happen in a case where a new main
division was added during the form editing process. The new option
would be added to the main division choices, but not the "other
division" choices. So . . . you'll need to *add* an option node to
the select node. If you are not using the filter interface, then
you'll also need to select that option.
So . . . a lot of words, not that much actual code. Here's the basic
idea below. In the case of using the filter interface, you'd add this
function as an onsubmit handler to the form. It's a little short on
error checking, but you get the point.
function() formSubmit()
{
var pcat_f = document.getElementById('id_primary_category')
if (!pcat_f) {
// This is not the form we're looking for . . .
// You can go about your business . . .
// Move along . . .
return true;
} else {
var form = pcat_f.form
}
// Get the id of the primary category
if (!pcat_f.selectedIndex) {
// validation will fail on the server side, so don't worry about it
here
return true;
}
// Create a new option node based on the selected primary category
var xopt = document.createElement('option');
xopt.value = pcat_f.options[pcat_f.selectedIndex].value;
var cat_f = document.getElementById('id_categories_to');
cat_f.appendChild(xopt);
form.submit();
}
--
-Ben
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
