Baishampayan Ghose wrote: > Yeah surely. I have discussed about this AJAX stuff at length on IRC and > my preference is shared by a lot of people and has been posted on the > list too. What I feel is that I know Django ``supports'' AJAX today > itself in a way that it doesn't restrict / stop the user from using some > third party AJAX library. But what I want in 1.0 is a loosely coupled, > minimal AJAX library + API which in one hand will enable the developer > to do some XHR stuff fairly easily and also on the other hand won't stop > him from using another full blown library if he wishes. Correct me if I > am wrong, may be what I said is not much ``buzzword compliant''. :) > Regards, > BG
The problem here is that this completely ignores the needs of the bundled apps, ie the admin - the most immediately visible part of Django. The future needs of the admin are expressly not limited to just simple XmlHttpRequest stuff - the admin should be full featured (whilst still maitaining lynx-workitude and full accessibility support) , and should also be created using best practices. This, I hope you agree, entails using some kind of Javascript framework rather than cobbling up our own bunch of IE workarounds or pulling random bits of JS together into an incoherent whole. The side effect of this is that some JS library would be included with django - people can take it or leave it. The desire not to make a decision about this just means that this work can't be done for the admin. ATM I guess I would have to vote for Dojo, just because it seems to attack the features that are desired, as opposed to MochiKit which seems to at this stage shy away from them. Not sure how the packaging / compression etc etc issues would be solved. I'm guessing a pre compressed version would be stuck into the tarballs, and a script for fetching dojo and doing the compression would be in the repository - I would prefer this to shoving a copy of dojo (or whatever) into the django repository. Robert
