Adrian Holovaty wrote: > I've been merging in the various non-admin-related changes from the > new-admin branch to trunk; it makes it easier for me to understand the > new-admin changes with the non-related changes out of the way. > > That part is finished, so the next merge is the big one. Before that > happens, though, I have a few questions. These essentially are > questions for rjwittams, but I'm posting them here in the spirit of > open-source. > > * What is the member_name parameter that has been added to some > FormFields in core/formfields.py, and why is it needed?
The membername thing is needed to make ForeignKeys work properly outside the admin. In trunk the last time I checked, they don't get populated properly - the problem is the whole name vs name_id thing - the FormField needs to know how to > * Can we refactor things so that RawIdAdminField isn't in > core/formfields.py? formfields.py is intended to be fully abstracted > from admin stuff -- they're just generic form fields for HTML display > and validation. The reason it is a seperate class is that it acts differently. The issue is that raw_id_admin at the moment is something that meta/fields.py deals with. Its never been restricted to the admin, its always affected every automatic manipulator. You could move it anywhere, and import it in fields.py, if you think it makes sense. There are other ways to fully abstract this, but they are a lot more work. (Extending the follow concept to allow overriding the FormFields a Field uses.) > * Could you explain the "follow" concept for RelatedObjects? Have you read the section in NewAdminChanges? > * Could you explain the BoundField, BoundFieldLine, FieldLine, > BoundFieldSet and FieldSet classes? FieldLine represents one line of fields in the admin. FieldSet represents a group of lines. All the Bound* versions of those classes represent a group of fields that has been bound to a particular instance of the top-level manipulator - ie they know where their data is going to come from, and they pick their formfields out of a particular formfield mapping (ie FormFieldWrapper or the like ) The user ( at the moment only the admin code) can provide a subclass of a Bound* field, so that they can add their own logic (attributes for layout issues, etc). This is the 'automatic form generation' code that I'm not entirely happy with, but I couldn't make any nicer without removing core fields. Also see BoundManipulator which I left in the admin code (contrib/admin/views/main.py) as I didn't think it was ready to stick into the main code. Eventually, I think it would be possible to : * elide the need to provide a formfield mapping, instead directly getting the FormFields out via get_manipulator_fields. Then the top level bound manipulator could act line a FormWrapper. * as some of these classes are pretty similar (FieldSet, FieldLine), merge them into a FieldGroup which can hold Fields or FieldGroups. > * There are several "TODOs" in the new-admin code. Are these taken > care of, or are they meant to point to future, post-new-admin work? I think they are for later work. > * The FilterSpec thing is really cool. :D Thanks.
