That's a very good idea, though I still think a short version (which is all I've written) belongs in the docs. Here's the relevant part:
Index: django/docs/newforms.txt =================================================================== --- django/docs/newforms.txt (revision 6979) +++ django/docs/newforms.txt (working copy) @@ -542,6 +542,14 @@ ``subject``, ``message``, ``sender``, ``cc_myself``. To reorder the HTML output, just change the order in which those fields are listed in the class. +If you can't change the declaration order to suit your needs--for example, +if you need to interpose a subclass's fields into those provided by a +superclass--you have two choices: you can specify the ordering in the template +itself, as described below, or you can write an `__init__` method in the form +class and set the value of `self.fields.keyOrder`, which is just a list of +field names. If you do the latter, don't forget to call the superclass's +`__init__` method before you set the `keyOrder`. + How errors are displayed ~~~~~~~~~~~~~~~~~~~~~~~~ Having a section headlined "Notes on Field Ordering" and then not mentioning that there's a way to get around the problem that you can't always control order things are listed in classes seems to imply that it's impossible. Todd On Dec 28, 2007 4:13 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > > On Dec 28, 2007 3:04 PM, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > > > > I have a use case where a Form superclass includes fields at the top > > and bottom of the form, with the subclasses providing the fields in > > the middle. Obviously, there's no easy way to fix the ordering using > > simple declaration. I went on IRC and someone told me about overriding > > self.fields.keyOrder in the Form's __init__ method, which works just > > great. > > > > I wrote up a patch for the docs that explains how to do this, but > > wanted to make sure the solution was kosher before I submitted it. > > While I expect that's great information to provide, it seems like it > might be a bit too fine-grained for inclusion in the regular docs. If > the docs included instructions on how to do everything last thing > Django's capable of, it'd be completely overwhelming to those who > don't need those features. > > Personally, I'd recommend you write up a wiki article on the subject, > reference it in the DjangoResources[1] article and post a link on > django-users so people know where to find it. Not to toot my own horn > (though I *am* a trumpet player, after all), but you could take a look > at the DynamicModels[2] and AuditTrail[3] articles as good examples of > how it can be done. > > Adding it to the wiki opens up the possibility for somebody else to > refine your work and add to it, as George Vilches has done with the > audit trail article. > > -Gul > > [1] http://code.djangoproject.com/wiki/DjangoResources > [2] http://code.djangoproject.com/wiki/DynamicModels > [3] http://code.djangoproject.com/wiki/AuditTrail > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
