Hi all,
Just a quick update on the refactoring of the dojo widget system. Things are moving along and the new code is much better performing / smaller footprint than the old code, which I know has been the #1 complaint against Dojo, so I'm pretty happy about that. There's also been a lot of work going into accessibility support, and AFAIK we are the only JS toolkit fully supporting that, so it's a major accomplishment.
I've noticed a lot of people are filing bugs and fixing bugs against the widgets in dojo trunk (basically the Dojo 0.4.2 release). This is worrisome because we are in the process of copying/refactoring all the widget code into a new tree, so the bug reports (and especially bug fixes) against the old tree may be unusable. Especially, bug fixes checked into trunk/ for code that has already been moved over will be lost.
On the other hand, the new tree isn't ready to use yet, so I'm not sure what to say. But if you are adventurous, you should try using the new code.
Milestone 2 for the widget system is on May 7, at which point I'll post some more info. After that we'll be writing more doc and a porting guide too. (Note that the changes in Dojo 0.9 for both core and the widgets aren't backwards compatible, so you'll need the guide.) In the meantime I've attached some slides about it.
| Attachment | Size |
|---|---|
| Dojo to Dijit.pdf | 57.03 KB |
Is the plan to release Dijit
Is the plan to release Dijit and Dojo 0.9 at the same time? And will they be packaged in the same tarball? (These questions may be answered at M2, but I happen to be writing the Quick Install section of 0.9 Manual at this moment).
I work on the XAP Apache
I work on the XAP Apache project, which uses dojo extensively. I have a widget wishlist, not sure if this is a good place but here goes:
1. Simplified creation of widgets from code.
2. Some cleanup of the layout stuff - in particular onResized(), isResized(), checkSize(), resizeTo() etc, fit together a bit akwardly - there is no resizeTo() that takes just a width or height instead of both, for example.
3. I see in the comments that there is no parent-child relationship so layout is being changed? What does that mean exactly?
4. Clean up memory issues around creating/deleting widgets. In particular dojo.event.connect will keep track of nodes that need cleaning but if you destroy a widget it doesn't get removed from that list. (the ie_clobber_nodes list) These get cleaned up when the entire app is destroyed by if you create/destroy individual widgets it leaks pretty badly last time I did thorough testing.
Overall the general approach described in the Wiki looks good, especially separating out a lot of the lesser-used widgets, removing the SVG psuedo-support and generally simplifying things a bit.
questions
1. Simplified creation of widgets from code.
Hmm, not sure what you mean by this one. We changed the way they are created but I'm not sure that it's easier or harder than before.
2. Some cleanup of the layout stuff - in particular onResized(), isResized(), checkSize(), resizeTo() etc, fit together a bit akwardly - there is no resizeTo() that takes just a width or height instead of both, for example.
Right, I want to clean this up too; will be working on it at 3DE (the dojo developer day in NYC).
3. I see in the comments that there is no parent-child relationship so layout is being changed? What does that mean exactly?
Well, that's an internal thing. there's no children[] or parent attributes anymore but there are getChildren() and getParent() mathods that figure out their return values by looking at the DOM. Previously there were two trees (one in javascript and the DOM itself),and now there's just the latter. getChildren() is only meant to be used for widgets where the concept of children is well defined. IE, SplitContainer has children but ContentPane doesn't, even though it might contain widgets.
4. Clean up memory issues around creating/deleting widgets. In particular dojo.event.connect will keep track of nodes that need cleaning but if you destroy a widget it doesn't get removed from that list. (the ie_clobber_nodes list) These get cleaned up when the entire app is destroyed by if you create/destroy individual widgets it leaks pretty badly last time I did thorough testing.'
We try to handle all this in the destroy() call for widgets but I'm sure we've forgotten some cases. This is definitely something we'll keep an eye on. And thinking about ways to make it more automatic. There's a lot of cleanup to be done but after the 0.9 beta, let us know if you see more issues.concurrent release
Yeah, we planned to release at the same time although we haven't given it a lot of discussion. Not sure about tarballs...