Wilson Miner wrote: > I think this all sounds great. > > 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. >
I've got to say, this plan sounds like it would lead to *another*, half featured AJAX library. Do we really want to reimplement everything? It seems like the world needs fewer JS toolkits, not more... Lets accept that other people are capable of waving the "extract from a working application" magic wand, and take a look at what they found rather than starting from scratch and recreating all their bugs.
