>Basically I >want to propose an implementation. At least I'll collect your thoughts, >criticism, corrections, and, hopefully, blessings.
Just some thoughts from me on this: it would make much more sense to address the whole Ajax stuff from a practical point - start adding stuff to the admin that needs Ajax or at least makes good use of it. Then we can see what we really need in Django for Ajax support. Ajax can easily be used with Django already, so there shouldn't be a big problem for Ajax enthusiasts to provide some Ajax sample apps that both highlight what can be done in that combination and what is needed. This can be integrated with the Django admin or it can be outside stuff - but it should be practical stuff that actually shows what is to be done. _Then_ we can discuss which of those emitting patterns we want to add to Django. Django started out as an "extracted" framework (in contrast to some "designed" framework, where the framework is first and the application is next), I think we should do the same for any Ajax+Django parts. A good start (and one that - at least I would think - many would applaud) would be to add support for search-suggestion to the Django admin search field. Another that comes to mind would be changing the two-column-stuff in the admin (used for permissions for example) to make use of Drag-n-Drop. One could be to revive the partly existing drag-n-drop support for element ordering. Oh, and please keep in mind that there should be at least a sensible fallback solution for those who don't want to (or plain and simple can't) use JavaScript all the time. Don't get me wrong: I am not completely against Ajax or JavaScript. But I am a bit wary of yet another approach to the problem from the "let's design a Ajax+Something framework" side, I've seen that far too often and far too often (even in this project already) it didn't really reach a point of useabliity or at least common agreement. Let's try something different and first provide problem solutions, and _then_ extract a framework out of them. There will allways be things that are "nice to have for a useful GUI" - but then there will allways be the "too much features" problem, too. At least when starting out with specific problem solutions and extracting framework characteristics from those, we won't fall for featuritis ;-) bye, Georg PS: my Ajax-driven heatmap btw. is gone: I changed it over to make use of plain and simple linking, as Ajax wasn't really needed to get the exact same useability - but using Ajax added problems like non-bookmark-ability of intermediate states of the heatmap.
