Subject: Dojo and Django
Newsgroups: gmane.comp.web.dojo.user
Date: 2006-01-28 17:09:22 GMT (2 years, 31 weeks, 6 days, 13 hours and 48 minutes ago)
Howdy -- For those that don't know me: I'm Jacob Kaplan-Moss, and I'm one of the lead developers of Django (http://www.djangoproject.com/). Starting with version 0.92 (which should be out in a few weeks, Murphy willing), Django is going to bundle Dojo with the toolkit. specifically as part of Django's admin interface (but available to user apps as well). After playing around with it for a while I think I have a good handle on how this is going to work, but I do have some questions I'd like to ask about doing things in the "best" possible way. 1. What's the best way to manage external libraries? I'm planning on making a ``django`` package so I can do things like ``dojo.require('django.widgets.many2many')`` and such. This is pretty damn easy (yay!), but it leaves me with a few lines of "bootstrap" code that has to be in every <head> before I can actually load the code I want. What I'd really like to do would be to have a single file that would take care of the bootstrapping steps so users could just do:: <script src="path/to/django.js"></script> and then get on with it. Is that possible? 2. How should I load widgets? Right now the widget situation in Django's admin is monstrous. Each widget has its own JS file (often with inconsistent style and idioms...) There's about fifty lines of Python code that figures out which scripts to include in a edit view based on which fields that object uses. This obviously sucks, and I want to fix it. What I'd really like would be to lazily load widget JS based on markup, but all the examples I've seen use invented attributes like ``dojoType`` or whatever. We're pretty committed to valid markup, so I don't think this is the best idea for us. Besides, all the form fields Django uses already have classes that can be hooked off of, so what I'd really like to do would be able to say that a given class (say, ``vManyToManyField``) triggers the loading of a given file (say ``dojo.widgets.many2many``). I can do this with a bootstrap script pretty easily, but is there a way for Dojo to handle this for me? 3. Lazy loading versus built-in code? Building Dojo with a custom profile is also pretty easy (double yay) but I do have some questions about the "best" way to handle it. It seems the "Dojo way" is to include in the build everything you want to use so that it can be cached and whatever. Problem is, for Django we have two different needs: a package to be used in the admin, and a package to be used in end-user apps. I can think of three possible ways to handle this: 1. One mega-build that everyone has to use. 2. Two builds (one for the admin, one for everyone else) 3. A single minimal build with the admin stuff loading lazily I'd prefer the third option, but it seems Dojo's users lean more towards the mega-build approach; is there a reason for this that I'm missing? 4. Managing the build itself? I could include the entire Dojo source tree in Django's SVN repository, updating it as Dojo releases future versions, and rebuilding the profile as necessary. It seems annoying to include all the build scripts and such in Django, though. Or, I could build Dojo outside of Django's source tree, maybe keeping the build profile and the built version in Django's source tree. However, this seems annoying since building Dojo for Django becomes an invisible process in a way. Does anyone here distribute Django with another OSS package? How do you/should I handle this? 5. Looking to the future... What's Dojo's approach to backwards-compatibility these days? What should I expect in terms of maintaining Django's Dojo-based libraries in the future? Thanks so much to anyone who got through this tome of an email, and double-thanks to anyone who takes the time to respond. Jacob (PS: Is anyone from Dojo going to PyCon? I would love to have a Dojo/ Django jam session at some point!)