I was taking a look at the latest patch [1] for #3639 (many thanks to Brian Rosner for the hard work), and trying to decide how backwards compatible we want to be. (I should also mention that while there has been some work done towards class-based generic views in #6735 [3], I believe that #3639 should be completed first as #6735 could be done post-1.0 if need be.) So, I come to the community for input...
Currently the create_update views take a required ``model`` argument and an optional ``follow`` argument. The ``model`` argument is fine and we can carry that forward. The ``follow`` argument, however, is specific to oldforms Manipulators and was used for showing/hiding form fields (see [2] for a refresher of the follow argument). In order to enable custom newforms-style forms, Brian has added a ``form_class`` argument to the views, which I think is the correct way to replace the functionality lost by the ``follow`` argument. There are a couple design decisions that need to be made, though: 1. Brian's patch replaces the required ``model`` argument with the required ``form_class`` argument, where ``form_class`` can either be a ``forms.ModelForm`` subclass or ``model.Model`` subclass. a. I am thinking that we should instead keep the ``model`` argument, but make it optional. Then, we ensure that one of ``model`` or ``form_class`` is given. ``form_class``, if given, would override ``model`` or if just ``model`` was given, then a ModelForm would be created for the passed model. Does this sound reasonable? b. Anyone have any other ideas here? 2. What should we do with the ``follow`` argument? a. We could drop it completely, which would not be backwards compatible for anyone using the ``follow`` argument. b. We could issue a deprecation warning if ``follow`` is used, letting people know that generic views now use newforms and to use ``form_class`` if you need a custom form. This would be a bit more backwards compatible, since if you aren't using ``follow`` everything should work the same. If you are using ``follow``, then those forms might display/behave differently (i.e. fields you were trying to hide now get displayed). c. We could be even more backwards compatible by trying to take fields declared in ``follow`` and make them includes/excludes in the inner Meta class of the generated ModelForm. I have taken Brian's latest patch and added implementations of 1a and 2b. Other additions were: * Fixed an error I was getting in the tests when using "model = model" in the inner Meta class (works fine in my shell, but gives me model not defined errors when I run the tests) by introducing a tmp_model variable. * Added a GenericViewError class and made a couple AttributeErrors use this Exception class instead since AttributeError didn't really fit. * Added a get_model_and_form_class helper function to remove duplicate ModelForm-generating code. * Finished off the test_create_custom_save_article test with a custom_create view that passes a custom form to the create_update generic view. I have attached my patch [4] to the ticket. Gary [1] http://code.djangoproject.com/attachment/ticket/3639/create_update_newforms5.diff [2] http://code.djangoproject.com/wiki/NewAdminChanges [3] http://code.djangoproject.com/ticket/6735 [4] http://code.djangoproject.com/attachment/ticket/3639/3639.diff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
