Login Register
Home » Blogs » bill's blog » Dijit 1.1 priorities

Dijit 1.1 priorities

Submitted by bill on Fri, 11/23/2007 - 03:51.

Hi everyone, I hope you've all had a good Thanksgiving (if you are in that part of the world).

Now that 1.0.1 is out the door, it's time to look forward to the 1.1 release and beyond. I'd like to do this for all of dojo but I can't boil this ocean, so I'm looking at dijit. I've gone over all the bugs against dijit, and especially the bugs marked for 1.1.

There are too many bugs to talk about individually but I've picked out the most salient issues, and listed them below. I'd like to get feedback from each of you, the dijit users, about the order of priority of these issues, since I don't think we'll be able to do all of them for the 1.1 release. (By "order" I mean an actual 1, 2, 3, 4 type list)

Architectural issues:

tree/datastore issues
  • dml/dnd not working - Updates to the tree (including DnD) are not working correctly since ItemFileWriteStore doesn't maintain referential integrity. Not a widget bug but affects Tree (#4552)
  • the dojo.data API doesn't support lazy-load of individual attributes, which means that an item (representing a node in the tree) must contain at the least a list of the id's of it's children, which is not a good model for lazy-load of tree children. Many people have also requested the ability to directly control the contents of the tree rather than going through dojo.data but we've resisted that as we want to keep dijit simple.
popup widgets' dom nodes moved to document.body
Popups and drop downs are moved to document.body, which breaks destroyRecursive() and reload of ContentPane via href etc. (#2056, #3300, #4902, #4980)
input widget layout bugs
For the 1.0 release I changed the input type widgets (*TextBox, FilteringSelect, etc.) to use a table for formatting so that you can specify the outer width of the element, including the width of the arrow(s), the error icon, and the input area. But getting this to work in all cases across all browsers has proven very tricky. Is using <table> unstable? (#5148, #4894, #5139). maybe need alternate design using padding
various textarea issues
(#5116, #5210, #3902). should we switch to using a plain textarea with resizing on kepress plus on a timer? (#4979)
layout widgets don't render inside dialog / hidden div
(#4169, #4263, #4758)
layout widgets in content panes
Problems specifying when underlying widget is layout widget and should be sized along with ContentPane (#5169)
splitting apart CSS files
Lots of discussion about the large size of the CSS needed to download with dijit, and how to reduce it.
use 4-corners technology for layout widgets
refactor of AccordionContainer, TabContainer, etc? to use 4-corners technology being used in Borderlayout (#3887). The tangible benefit here is smoother screen resizing for something like the mail demo (this is especially an issue on FF).
dojo.requireCss() / race condition loading CSS
People have asked for synchronous load of CSS files to avoid race conditions, and also to fix path problems with IE's filter() path (which is relative to the html page, not the CSS file location) (#5136)

A11Y:

I don't know much about what's on the list for A11Y. A few highlights are:

grid
finish a11y for grid (#3813)
dialog initial focus
focus on first item in container not dialog itself(#4025, #4411, #4413, #5133, #5134)

New features:

MenuBar
We have toolbar but it's behavior is subtly different; people want a real menubar. (#4634)
tooltip position
support specifying tooltip position (above/below/left/right) of target node (#5214)
button size specification
Similar to the way the input widgets were changed for 1.0, allow user to specify outer size of button widget. (#5211) Don't forget that (for themes like noir) the button size can include maybe 20px of images for the button border itself, so presumably specify style="width: 100px" would give 80px to the content and 20px to the button image.
separate display/edit mode for CurrencyTextBox etc.
Separate display and edit mode for form widgets, like in Excel (#4511). Looks like this is a simple one; Adam has a patch already that's only a few lines of code.
Form widget work
  • prevent submit if invalid values (#4692)
  • support native input fields inside Form widget (#4408)
  • repeater widget for repeated sets of values (#4693
filtering TimeTextBox
TimeTextBox that works like ComboBox (http://dojotoolkit.org/forum/dijit-dijit-0-9/dijit-development-discussio...)
BorderLayout
This makes it easier to do typical layouts like the mail demo (#4117), and is also a testbed for the the 4-corners technology. Eventually may be expanded to have advanced features like EXT's BorderLayout such as opening/closing the side panes, and automatically creating tab container if (for example) there is more than one pane in the "left" position
doLayout=false support
Ability to have a tab container or stack container where you don't specify a size (like style="height: 300px") but rather it sizes according to it's contents. (#3450)

Additional browser support:

FF3
In particular this relates to using contentEditableDiv for textarea/editor on FF3, but there are other bugs too. Another issue here is with timing... I'd like to have FF3 support in the trunk rather than having to do it in the 1.0 branch but I guess that FF3 will be released fairly soon, perhaps in January?
Opera9

Misc:

RTL support
Support for right-to-left scripts like hebrew and arabic
soria
get soria theme working again, and merge CSS improvements (having multiple patterns pointing to the same CSS rule set into tundra.css.
templateCssPath support?
see also "splitting apart css files", above. we removed templateCssPath support from widgets as a simplification for dijit, but that doesn't work very well for user defined widgets or widgets in dojox.
automated tests
  • DOH - we can write DOH tests that check simple things like whether the widgets can instantiate without getting an exception, but they would only test 10% of the functionality. People would still need to load all the test files (in all the browsers) to see if the widgets were really functioning or not
  • Selenium - we can write selenium tests for the widgets. These would test a lot more, but are probably very time consuming to write and maintain.

Regarding automated tests

Submitted by davidb on Fri, 11/23/2007 - 15:00.

I think they are time consuming, but so is fixing regressions ;)

Just imagine if we had good coverage using DOH and Selenium or Windmill? It would be awesome to have these tools catch bugs before they are committed.

I'm willing to do the work pushing automated ui testing forward, but my time has been very limited lately, and I'm off for all of January.

CSS based layout for input widgets

Submitted by remi on Fri, 11/23/2007 - 15:14.

The "input widget layout bugs" are not funny. I use YAML as CSS framework together with DojoToolkit. It works with DojoToolkiit V0.9, but not with the new table layout from V1.0.1. Couldn't we create a CSS based layout for these widgets, instead of using tables?

Remi

What I'm working on

Submitted by iTorrey on Fri, 11/23/2007 - 17:31.

Bill,

I agree with what you have so far and am adding in a couple of things I'm working on.

1. Updated Tundra theme. This is actually very far along, you can see it at http://dojotoolkit.org/~itorrey/tundra_upgrade/dijit/themes/themeTester.... just some minor clean up to polish things up a bit.

2. Widget 'personas'. I started working on a persona for each widget which describes the types of uses for a widget. This would help newcomers as the persona would describe in a few sentences the basic ideas behind the widget. I'm also currently cooking up a webapp theme for examples... the idea being we would create an example app (like the mail demo for instance) that would use all of our dijits. Each dijit would have a demo file which has data relating to that theme. For instance, if we went with the communication hub theme we might style the accordion pane to be our buddy list and a floating pane might be our IM conversation and within that might be tabs to switch between the conversations. Still working on fleshing this idea out.

3. As part of a SitePen blog about creating themes for Dijit I'm working on a style that we'll contribute as well.

iTorrey, tundra looks way

Submitted by nonken on Thu, 11/29/2007 - 19:42.

iTorrey, tundra looks way better!!! much cleaner and not messy anymore!!
I have worked on a theme nihilo as well http://www.nikolaionken.com/dojo/images/dojo-nihilo_03.png maybe we can implement this one until the 1.1 as well? xnihilo needs cleanup though

Personas

Submitted by davidb on Thu, 11/29/2007 - 19:54.

I'll be interested in seeing these (if they materialize).

menu need, css spliting nice

Submitted by Devanchya on Sat, 11/24/2007 - 00:47.

I have to say, the fact there's no real menu with Dojo is the #1 complaint I've gotten when discussing it with other users.

Css splitting would help with the total size of the download. Ability for them to dynamically load as needed as required would help. I'd also like to have the ability to easily move the css files to a secondary location for easier management with other site CSS files.

please no more CSS splits

Submitted by remi on Mon, 11/26/2007 - 02:31.

Oh, please no more splits with the CSS files. Each request for another additional CSS file costs more and more time. A big CSS file is better than twenty small CSS files.

Remi

while i would want to agree

Submitted by dante on Tue, 11/27/2007 - 14:32.

while i would want to agree with you initially, the sheer size of the css in the cases where you are not using all the widgets is cumbersome in itself. dijit.css i think clocks in at ~20k, and tundra.css another ~30k (?), just to use a single dijit. If the dijit used it's own theme css file, in development mode you would incur the hit of the multiple css files, but the build system could/would/should be utilized to roll the required css files into a single common file, and strip comments. which is about as optimal as it could get, imho. if you end up using a lot of dijits, the css will be one big file, otherwise, it's one much smaller file. this would also make it possible for dojox css files to be included in a theme file (for instance Lightbox provides definitions for both soria and tundra styling) and not have to be a separate include. One appealing idea would be to make each widget use it's own css file, and not actually tie it to the JS at all, but rather make (for example) tundra.css something like:

/* tundra.css definitions */
@import "TitlePane.css";
@import "FilteringSelect.css";

and then you could manually strip out the files you don't need, and have an easily parsed list of files to roll into a single project.css file (your own css included, potentially)

no real menu

Submitted by bill on Tue, 11/27/2007 - 14:22.

When you say "there's no real menu", you are talking about the MenuBar thing, right? Something like the horizontal "File" menu at the top of windows on Microsoft Windows, or the top of the screen on the Mac.

Tip: use a alternative menu

Submitted by remi on Tue, 11/27/2007 - 14:43.

Devanchya, you can always use a CSS based drop down menu, like the great ADxMenu.

Remi

Tree widget

Submitted by msmith on Fri, 11/30/2007 - 02:00.

For me and my company, the tree widget is a very high priority. We're actually waiting for the tree widget to become more solid before porting our main application to Dojo 1.x. Improvements to DnD are the main thing that we're looking for. Thanks for posting the question. ~Michael

splitting apart CSS files

Submitted by jbondc on Sat, 12/15/2007 - 15:36.

Hi everyone, just letting you know that I begun attacking splitting the CSS files.

It's based on the idea of creating a 'minimalist' build of only the resources you need. See this ticket:

http://trac.dojotoolkit.org/ticket/2696

Not sure on delivery time but hope to be done sometime in end January 2008