Hi all,

With the deadline for 1.3 alpha rapidly approaching, it's getting to
crunch time for class-based views.

The wiki page [1] now contains a good summary of the debate so far,
showing why we have ended up at the "ClassBasedView.as_view()"
deployment solution. I've also got a implementation up on my bitbucket
repo [2] (in the class-based-views branch) that is integrated into the
Django source tree.

I've done an audit of the simple (template and redirect), detail and
list views, and I'm reasonably happy with the feature set, feature
parity with old-style function views, and test coverage. I've also
checked that the outstanding generic-view tickets (#1282, #2367,
#8378, #9150, #12669, #13753, and #13953) are solved or are solvable
using the new class-based framework.

The following things are still needed:

 * An audit of create/update views.
 * An audit of date views.
 * Documentation, including
    - changes to the tutorial
    - topic documentation
    - reference documentation
    - a migration guide for function generic views to class-based generic views
 * Feedback from the community on the API that has been exposed.
 * Fixing Django's handling of PUT requests (this currently raises an
expected failure in the test suite)

Unfortunately, the 1.3 alpha deadline is Monday. Over the next couple
of days, I intend to finish my audit of edit and date views, and make
a start on at least reference documentation, but it's highly unlikely
I'm going to get all the items on this list done by Monday.

So - I'd like to field opinions on committing class-based views in an
'almost finished' state.

I won't commit anything until at least my review of create/update and
date views is complete. In particular, I'm not especially happy with
the current state of the create/update views. I'd also like to see a
couple of independent reviews of the API as a sanity check.

Then, during the beta period, we will need to expand on the
documentation and finish the other outstanding items. I would also
expect to see some minor tweaks to the API as different use cases
emerge. Some of these changes may be backwards incompatible, but I
don't anticipate any widespread changes being necessary. Once we hit
beta, I would anticipate that any backwards incompatible changes we
need to make will have shaken out.

One piece of evidence supporting this plan: history has shown us that
we don't really get much serious testing of new features until they
hit trunk, and we don't get the *really* serious testing until a final
release is made. Getting an 'almost finished' version into trunk may
actually help the feature develop faster than it would if we postponed
to 1.4, hoping that it will mature in a separate branch.

Any opinions or objections to this plan?

[1] http://code.djangoproject.com/wiki/ClassBasedViews
[2] http://bitbucket.org/freakboy3742/django - (class-based-views branch)

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.

Reply via email to