Hi all, I've just added a summary of the last thread on class-based views [1]. This summary isn't 100% complete -- any contributions from interested parties are welcome. Try to keep opinions to a minimum; this page is about documenting the strengths and weaknesses of various approaches, not about expressing opinions. In the same way that CSRF [2] and session-messages [3] have good wiki pages describing the design considerations, we need to be able to explain to future generations why class-based views are the way they are.
Based on the discussion on the most recent thread [4], plus in-person discussions, I'm proposing that we move forward with Ben Firshman and David Larlet's "__call__ + copy()" approach. Yes, the copy() is a bit of a weird idiom, but it's not an idiom that users need to be particularly concerned with; the code "just works" in an unsurprising way. The other viable option is the __new__ based copy; however, this approach is also idiomatically surprising (instantiation returns an object of type other than the object being constructed), and it doesn't allow for the use of arguments at time of instantiation. I'd like to try and get this in for 1.3. It's a big feature, which means it needs to be in by October 18. However, based on the state of the patch that Ben has prepared, I think this is an achievable goal. Three things are required to make this happen: * Documentation. It looks like David Larlet has made a start on this already, but there's lots more required. * Conversion of the github project into a patch on trunk. * Feedback on the API, especially the generic view replacements. If you have any feedback, drop it into this thread so that we can integrate the changes. If you are interested in helping out on the first two points, drop a line here too so that we can coordinate activity. I already have one specific piece of API feedback: the current implementation requires that all view logic is contained in GET(), POST() etc style views. This is fine, except for the fact that there are occasions where GET and POST share a lot of common logic. It would make sense to me to allow for a request() method that is the direct analog of how we do views right now, wrapping lines 53-59 of base.py into a request() method. This would allow users to define their own dispatch mechanisms, or share logic between GET and POST (and any other http method) as necessary. [1] http://code.djangoproject.com/wiki/ClassBasedViews [2] http://code.djangoproject.com/wiki/CsrfProtection [3] http://code.djangoproject.com/wiki/SessionMessages [4] http://groups.google.com/group/django-developers/browse_thread/thread/e23d9a5a58fe5891 Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
