About Kabuki/Dojo - Zimbra is open source in the sense that they have a CVS respository with a Mozilla 2/ ASF license, but I don't think they take contributions back or engage in any sort of community development. The Zimbra set of components is missing a bunch of stuff, for example there is no splitter. (I wrote one myself that's checked in now) While we can mix and match components from different toolkits it will probably be easier to implement the core set (combobox, button, textfield, etc) with one toolkit. Dojo has a bunch of widgets, are working on a "widget release", other guys like Turbo Widgets are building Dojo widgets and it seems to me that it will be easier to contribute back to Dojo. I do sadly have a Xap and xap. That's because xap is the namespace and Xap is an object. Typically namespace naming is lower-case and object naming is uppercase. (So my brain got confused) Maybe it would be best to simply rename the Xap object to something else that is more descriptive to boot. Or just make it 'xap' everywhere. That might be for the best as it only introduces a single top-level object, even though it is a bit weird to have a lower-case object with methods on it. Anyway thanks for your great feedback so far! I tend to work quickly but I also am completely willing to undo changes when they don't make sense. I typically engage in a rapid-prototyping / iterative development sort of style. I don't have any problem with someone saying "those changes you made last month - I looked at them and they don't make any sense!" James Margaris
________________________________ From: [EMAIL PROTECTED] on behalf of Martin Cooper Sent: Wed 6/28/2006 8:59 PM To: [email protected] Subject: Re: Commits finished, dojo integration, etc On 6/27/06, James Margaris <[EMAIL PROTECTED]> wrote: > > I'm done checking everything in, sorry again about the spam, there are > issues with the eol-style in the dojo code. Strange. I just did a spot check on a few files in Dojo SVN and they all have an svn:eol-style of 'native', which is fine. Maybe I was just "lucky" in the ones I spot-checked. ;-) An overview of what I did: > > We now use dojo loading for all files except Zimbra files. Excellent! (Those don't > work with that system and we will remove them eventually anyway now that > Kabuki is dead?) Good question. While Kabuki is dead, my understanding is that Zimbra itself is still being open sourced. But I'd be fine with removing them in the meantime, until we see what's really going to happen there. Dojo loading gets files and calls eval() on them. I had > to make minor changes to every file and major changes to the google > stuff to get them to work in IE as eval() there has some scoping issues. > > Xap.provides(), Xap.requires() and Xap.kwCompoundRequires() are wrappers > around the Dojo calls of the same name. Those are used in a couple of > places, for example xap.util.Character uses provides() and the things > the use Character use requires() on it. Eventually everything should do > the provides()/requires() stuff but I wanted to just put it in a few > files as a test and to let people see if it looked OK or not. Do you mean 'xap.provides()', etc., rather than 'Xap.provides()'? I assume we have only one 'xap' namespace. ;-) The bridge classes specified in xap/taghandling/plugin.xml are now > loaded dynamically. > > After people get a chance to digest these changes, provide feedback, > etc, if everyone is in agreement I (and anyone else inclined) can begin > moving things over to use provides()/requires() and to use the proper > xap.* package naming. My feedback is going to be late, I'm afraid, since I just started at a new "day job", and I'm off on vacation for two weeks starting this Saturday. Not that that should stop you, of course - just a heads up that I won't have a chance to really dig in for a couple of weeks or so. -- Martin Cooper Some of the doc produced by JSDoc is a bit screwed up, when I changed > the constructor style it lost the ability to find the constructor > without the @constructor tag, so I will try to make things nice again > there. > > James Margaris >
