I also think Adrian's point in his post about AJAX support is very valid here. Any support for AJAX in Django should come from real needs in a real project.
As Rob pointed out in an earlier thread, once the new-admin changes are rolled in, the project to fix the edit_inline interface is going to require some basic AJAX ( e.g. drag-and-drop ordering, adding/deleting table rows, etc). And as Simon pointed out, the admin changelist is an obvious target for some basic AJAX magic (e.g. live search, live filtering)
I think the best way to go about adding AJAX to Django is to add it where it's needed and obviously useful in the admin app, build the necessary support layers along the way with a mind for abstraction, then extract those techniques to an extensible sub-framework that we can build on.
That way we have real tools from real needs, no theoretical "we might need this if" cruft, and a good repository of real world examples and use cases in the admin app. And thanks to Rob's work in the new-admin branch, all those examples and the initial functions will be prime for reuse and expansion in other apps.
On 11/14/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]
> wrote:
Hey folks --
Man, it's fun having such smart and passionate people on this list!
I've been thinking about how Django might leverage DHTML^H^H^H^H^H
AJAX a lot recently, and I think the framework I'll sketch out below
should make a bunch of people happy.
As I see it, there are three layers necessary for doing Django-AJAX:
The first layer will be a package -- django.core.serializers, most
likely -- which exports a set of serializer/unserializer libraries.
These libraries will know how to convert Django objects to and from a
specific format; we should most likely have XML and JSON serializers
at first crack, and XML-RPC and SOAP serializers could be quite useful.
The second layer will be a set of views not unlike the
django.views.generic , except that they'll take and produce data in
one of the formats defined by the serializer and be nicely RESTful
(appropriate use of HTTP verbs and such). So you'll be able to do
something like::
urlpatterns = patterns('',
('^rpc/', include('django.conf.urls.rpc')),
)
and get slick web services for free.
The third layer will be a toolkit that abstracts those views into
_javascript_. I'm afraid that picking a _javascript_ framework is going
to turn into a bikeshed argument, but as long as whatever we choose
can seemlessly hook into the CRUD views, we should be OK. The idea
is that in _javascript_ I should be able to do::
entries = rpc.get_list ('blogs.entries', {'limit' : 15})
(or something) and have it Just Workâ˘.
As I see it, these three bits should be written in a way that's
consistent with the rest of Django's philosophy: it should be very
easy to use all four together, but they should be loosely coupled so
that any layer could be used without the others. That way if you
don't like the _javascript_ wrappers, you can always write your own.
Or, if you don't like the way Django does CRUD, you could roll your
own CRUD layer.
How does this sound to everyone?
Jacob
