On Mon, Jul 6, 2009 at 8:38 PM, Joshua Partogi<joshua.part...@gmail.com> wrote: > Dear all, > > Not trying to flame here, but I've just read Jacob's post here: > http://article.gmane.org/gmane.comp.web.dojo.user/3603 > > What made django developers changed their mind not to bundle dojo in 1.0 ? > Is there any history to that?
History is definitely the word :-) You need to keep in mind that the post you are referencing is from early 2006. As a result: - Project-wise, it occurred during the magic-removal phase of Django. This was a time when there was some very big changes happening to the Django codebase. - There never was a 0.92 release - we jumped to 0.95 when we formally finished the magic-removal branch - The project was still young, and while Malcolm, Luke and myself were all core developers, the project was still very much in the "BDFL say, project do" phase. - The BDFL's were both working at World Online, and a lot of the development on Django was driven by their requirements. James Bennett was working on Dojo/Django integration as late as April 2006 [1]. I can't find (nor can I remember) a single moment when a decision was made, but: - James called for comments on his Django/Dojo integration, but the code was never committed [2] - Around the same time, jQuery, mochikit, YUI, and about a dozen other javascript toolkits started getting traction. As a result, every time Dojo was mentioned, a bottomless thread of "why not toolkit X" would start. - The focus moved from magic-removal to newforms. One of the goals of newforms was to make it easy to define widgets that could control their own rendering so that they could be easily replaced with javascriptified rich widgets. By September 2006, Adrian had stated a preference to avoid blessing any particular javascript framework [3]. By virtue of BDFL pronouncement (and silent agreement from the other core devs) this pretty much became official policy by virtue of repetition soon after. I think this policy has served us well. By staying out of the Javascript wars, we have let Django do what it does best - handle the serverside - and let developers pick the Javascript toolkit that suits their needs best, be it Dojo, YUI, jQuery, or custom inhouse JS code. That said, this may be about to change slightly. One of the Google Summer of Code projects is reworking bits of the admin, and one of the parts of this rework is looking at introducing jQuery for some of the styling and widget requirements. This won't fundamentally change Django's policy: the Django Core won't be blessing a javascript toolkit. However, the contrib application that is contrib.admin may end up using jQuery as a way of implementing some more advanced features. Any jQuery code will be limited to the admin interface - we won't be requiring that end users adopt or use jQuery in the sites they deploy outside of the admin interface. Yours, Russ Magee %-) [1] http://groups.google.com/group/django-developers/browse_thread/thread/93d27da525d75c00 [2] http://code.djangoproject.com/ticket/1613 [3] http://groups.google.com/group/django-developers/browse_thread/thread/5160ff09f80fee9a --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
