Hi all. For those of you that don't know me, I'm in charge of Dijit. We are just wrapping up the Dojo 0.9 release now (btw, download the nightly and start testing). Now's the time to look forward and see what widgets people want for 1.0 and beyond, both in Dijit and DojoX.
There are a number of missing features from 0.4 that need to be added to 1.0, especially table, tree, charting, and maps. We know that everyone wants table, and better tree features, and we'll have something soon.
But what else? What new features do you want in upcoming releases? What about the current system that you don't like? The Dojo community wants to know. I've been working on a roadmap for Dijit but I want to get everyone's input.
Also of course, I'm always looking for volunteers to help with development.
Bill
Note that the maps...
...will be ported and highly augmented in the upcoming DojoX Geo project. If you have any requests, feel free to comment at:
http://dojotoolkit.org/forum/dojox-dojox/dojox-development-discussion/ca...
Charting widgets will also be provided at some point with the DojoX Charting project, which is in progress.
Widgets that I miss:
Widgets that I miss: editable table widget and paginated table (with some server interactions).
Also, there is a bug in modal box dialog: if I resize the browser window with modal dialog box opened, the background shadow layer is resized slower than the browser window and I can see the shadow is trying to run down the new size of browser window.
I want also to control the behaviour of the modal box window when I resize the browser window. I need the possibility to say the modal box to keep centered horizontally and vertically, or only horizontally, or to keep 200px from the left.
LayoutContainer with flexible height
I wish a LayoutContainer with flexible height similar to the current one... but with a client area that may be bigger than the browsers height
a nice addon would be a flexible width, so that the areas at left, client and right adjust to the browser width... small example:
a browser width of 1000px could have a left and a right bar having 180px width each and for a browser width of 1400px, left and right could have 250px width each... aim is to support resolutions from 800x600 up to 1600x1200
Lightbox and Fancy Upload
One "widgets" that I really miss in Dojo and use in other frameworks are a Lightbox/imagebox thing ( like jQuery plugin Interface's imagebox: http://interface.eyecon.ro/demos/imagebox.html )
Another that I have just recently discovered and thing is very awesome is a multiple file uploader such as the Fancy Uploader for MooTools: http://digitarald.de/playground/uplooad.html - it allows you to select multiple files and upload in one go (no browse, add, browse, add, browse, add... for each file)
I am working on a lightbox
I am working on a lightbox widget to land in dojox.widget
I don't want to call it lightbox. any suggestions?
Nice, when do you think this will be released?
Picture Popup?
PicPop?
Looking Glass?
Magniview?
hmmm, with the
hmmm, with the release-candidate out today, and needing a strong focus on documentation, I'd say not before 0.9final ... Would someone mind creating a dojox developer forum thread to discuss the API ... and name? :) I am curious what kind of features people would want, or don't want. there is an implementation i am trying to duplicate called "Lightbox2" ...
some of the animation code has landed in dojox.fx already (dojox.fx.sizeTo), but am deferring the real hard work until after the stable part of dojo is official, and stable :)
it will definitely [ok, "more than likely"] be _before_ 1.0 though.
I've got a working 0.9 image gallery...
I too am working on a 0.9 based image gallery. It is more or less finished now, you can see it at http://www.skynet.ie/~sos/test_ImageGallery0.9.html
I've integrated it with the Flickr API through using a customised data store. The widget itself is built on top of the dojo.data API. A 0.4.3 version is available at http://www.skynet.ie/~sos/ajax/imagegallery.php.
The finalised version should be ready in the next week or two. I've already chatted with the dojo contributors and they're open to committing it to dojo if certain goals are reached - running on top od dojo.data for example.
Shane
i've seen the 0.4 version
i've seen the 0.4 version but not the port. We should collaborate and see if we can deprecate dojo.presentation.SlideShow with yours, or extend it to work on to of your store, or something. Redundant code is no fun :) Seems like SlideShow would be better serving as an imgNode with an api to a) set a new image with a fade transition after load via dojo.data (or after a set delay on a simple arrayStore) and be able to jump to a specific image via a click on a thumbnailList widget or something (much like a stack container + buttons) but images, and accounting for loading time of the image ...
Redundant code makes me a sad panda
I totally agree, redundant code is to be avoided. However, I think that separating this out into two widgets is a mistake. Instead of that, it would be better to simply allow the user to enable or disable thumbnail views of the pictures, which would leave them with a standard Slideshow widget, albeit running against the dojo.data api. Keeping it as one widget (or two widgets in a child-parent hierarchy) enables us to make sure that is displayed in a sensible aesthetic manner, rather than having two separate widgets that could be placed anywhere at all on the page.
Dialog widget as prototype for image gallery
I have a working prototype here:
http://www.nightlifemagazine.ca/portmanteau/evolution/
My beef (tofu?) with 0.9 is that the flexibility of dialog is no longer available, with the documentation explicitly discouraging that dialog be used like in the aforementioned link. A fancy pop-up replacer for images what I, possibly others, need.
Your image gallery is really cool, but it's overkill for me personally. I will not be handing off the navigation to javascript, I will not be pre-loading the images 5-10 at a time (each time I press the arrow i'm downloading =~ 500k weather or not I look at the pictures?!), etc.
So yeah, I need a pop-up substitute. Dialog was it in 0.4, but in 0.9 it ain't.
Cheers.
well the point of the
well the point of the datastore and making the flikr store a separate thing would just make it that. you could just use a list of images to slideshow, or write a complex datastore that matches a query, or use the flikrstore, etc ...
the cavet i've run into making the 'lightbox' is how difficult Dialog is to extend, so will probably end up making a whole new widget.
that's a nice looking prototype, btw.
Preloading can be disabled if necessary
The preloading of images is an optional feature and can of course be disabled on a widget, if bandwidth is an issue. It is only there so that the user doesn't have to wait for an image to display, but if you're comfortable with adding a delay to their experience, that is of course possible with the widget.
LayoutContainer with more than one client area
Talking about wishes I would like LayoutContainer to have more than one client area.
I explain myself: If there are more than one client area, height/width is distributed between these areas; i.e: We have a layout container with 3 children and a height of 400px: first is tagged as 'client', second is tagged as 'center' with a height of 100px each one and the last one is tagged as 'client' again. With this add-on, first and third containers gets a height of 150px each one, and we can have easy layout centered in height, a thing that is not very simple with css.
Keep going with all that good job, guys!
Methods in all widgets to change text
Another thing I would like for dijit widgets are some methods to change all text defined in them dinamically.
I need this because I'm developing a multilanguage application which needs to change the language of all texts in screen in runtime. To do this I connect all widgets with defined text with my multilanguage manager and when I change the language of the application, all texts are changed.
Actually I have to write a wrapper over the widgets I use to add them a method to overwrite the defined texts, but I think these texts should be all able to change dinamically.
I'm actually working with a nightly build of 0.9 dojo and I'm waiting eagerly the release of 0.9
Dynamic language support might be expensive
Dijit is currently built on top of the Dojo core i18n support which is built on top of the Dojo loader. In the interests of keeping it simple, we don't try to manage resourcev changes at runtime, much the same way our code loader only knows how to require or load code, not unload it. It would seem to add a lot of weight and complexity to support this requirement, not to mention a rewrite of critical core code, so I'm doubtful we can do this, but we should take another look.
Your seems like a special case. Usually, changing language is something that would happen once per session, or perhaps even once during the life of an application if the user's preferences are stored. We do currently support a lang= attribute, like HTML, which you can use to support multiple languages on a page. Has this been useful to you? I've actually received a lot of pressure to drop the feature :-/
Is it possible for you to achieve the desired effect with custom widgets, binding to the multi-language strings explicitly and swapping them out as needed? Perhaps you could even use something like dojox.wires to do this?
-Adam
That's is the way I'm working
Yep, that's the way I'm doing that, writing my own custom widgets and adding some methods like the setLabel one to change text in widgets.
I think the lang=attribute is a very interesting way to manage multi-language, but I have my own language text sources and I need to use them.
I don't know very well how the dojo.wires works. Perhaps is there some information about using it?
Thanks
My wish list
Hi Bill,
Working with Dojo widgets has been great - my wish list:
1.) Documentation improvements - maybe it's just me but I have a hard time finding information about widgets, what attributes you can use, etc. For example a little while back I was trying to find out if FloatingPane could use refreshOnShow, I tried the api docs first but that only shows the methods defined in FloatingPane not the attributes it supports or what attributes it inherits. So I had to dive into the source to figure this out, which in 0.4.3 doesn't have the nice comments that it used to. I also tend to learn what widgets can do by looking at tests/widgets in the distribution - which works ok for me but I always feel like there could be a better way.
2.) InlineEditBox - I have to customize this widget if I want to assign it some custom property - say I have a form where I use this widget to allow someone to edit an item's description on a page of many items. In order for this to work I've had to make a custom edit box that has a property itemid that I can set/get so when the user presses OK I know what itemid they are editting. There's probably a better way to do this though.
3.) A simple confirmation dialog would be nice - I think I remember seeing somewhere this was being added.
4.) Validation textboxes - would be nice to have more control over where the validation message appears. If you have a page with a lot of input elements close together and someone enters invalid data, the message can muck up your layout - it'd be nice to be able to indicate that the messages should show up in a dialog or a
5.) Validating RegexpTextboxes with dojo.validate.check is goofy because you have to declare the regexp twice, once for the widget and once for the validation profile constraints.
6.) DropdownDatePicker - if I want to select my birthday of 2/25/1975 I have to click the year text 30+ times to get to 1975 - can there be an option to have the year as a dropdown?
Thanks!
Josh
I forgot
Anything to enhance file uploads would be great. I use IFrameIO now, which works great, would love to be able to hook in a progress bar somehow though. Supposedly Coccon has something: http://blog.fiveone.org/2006/11/good-progress.html - but that doesn't really help me much. :)
Documentation & Improved FilteringSelect
Dojo is in a great position to be the dominant AJAX toolkit for Java developers in the coming years if the documentation is brought more up to speed. The new 0.9 Dijit documentation is a good start.
Each page should provide:
For applications that deal with large lists of server side data, we need to be able to send dynamic request parameters with the URL to the server to filter lists. The Dojo 0.4 Select allowed this but the new FilteringSelect takes away this capability.
FilteringSelect and large lists
That's what I also need:
see:
http://dojotoolkit.org/forum/dijit-dijit-0-9/dijit-support/filteringsele...
Re:
Agreed - All attributes/methods is huge, including links to the widgets it inherits from as well.
It'd also be nice to have those image links pop up a simple working demo of the widget instead of just a slightly larger static image.
I hope I don't sound like I'm whining, I'm pumped for 0.9 and looking through the 0.9 dojo book on widgets it's hard not to start drooling with all the great stuff you guys have put together. I wish I had more time to contribute to docs but I'm unfortunately too da#n busy.
Josh
FilteringTable
... Or any other table with a similar Data Store backing. Please.
I know this is already listed above, and I know you guys are already getting lots of email on this one, but *most* users of 0.4.x are not going to be able to migrate to 0.9 until a reasonable table is there. Any other wish list items I might have are just gravy relative to this one. I'm sure there's some challenge I don't fully understand in making this happen, and you guys are doing an *unbelievable* job as is, but I just wanted to reiterate that this widget will make or break whether many, many people can use/test/play/extend 0.9.
Any chance for 0.9.1 with Filtering Table?
Thanks so much,
Matt
...an advocate of Dojo in the Enterprise
documentation.create() and documentation.extend() methods
We need documentation.
One should believe, that each developer is able to document his work together with a explanation of the underlying concepts. But look at the current results in the Dojo Book 0.9. The most used page content is the word "TBW". The mailing list and the forum is full of comprehension questions, because of the lack of documentation.
And unfortunately that's always the same problem since years in this project. The "community" should do that, but the "community" isn't able to do that. It's so frustrating.
You shouldn't allow the developers to develop new Widgets without pressure to deliver them together with a good documentation.
Remi
...who likes the DojoToolkit, but can't recognize a progress with the documentation tasks
Some stuffs
- filteringTable with :
. ability to populate with json and to make links between names ! (ex : 'id' field of the table => 'toto_id' of the JSON data... Very useful !)
. filter in top of columns (ex : typing 'toto' in a text field in the top of the column 'name' only shows lines containing 'toto' in their name)
. same as filter with lists instead of text field. If the 'name' column is populated with values 'toto', 'titi' and 'tata', a list in top of column 'name' will contain 'toto','titi' and 'tata' values. Selecting one of these values will filter.
. paginating data, with options of pagination : number of elements by page, ability to go to last element, or to page n° x, ability to still use filters and sorting
. hidden fields
- combobox (or eq.) with pre-selected value possibility ! - ability to simply define default value (not always -1)
- GFX !!! With text, images, drawing (in 0.4, this is a very powerful tool, congratulations), and more compatible with opera and safari (I know I'm asking for the impossible), and maybe special effects ?
- Simple javascript code to close current dialog (ex : dojo.closeCurrentDialog) even if I don't know its name.
- Javascript execution set to "true" by default in contentpane (and similar)
- ability to execute javascript function automatically after loading new content in a contentPane, like , but for a contentPane.
I hope I am clear enough, some things are not easy to describe ;-)
Thanks for asking users their wishes ...
Re: Some stuffs
Manuv,
Some of your requests regarding FilteringTable are already here today.
ability to populate with json
This is already a major feature, as FilteringTable has a backing data store which you populate with an array of "json" objects. For example:
var userObject1 = {
Id:101,
fName:"John",
lName:"Doe"
};
var userObject2 = {
Id:102,
fName:"Curious",
lName:"George"
};
var myArray = new Array(2);
myArray[0] = userObject1;
myArray[1] = userObject2;
dojo.widget.byId("yourFilteringTableID").store.setData(myArray);
... Assuming you have fields (columns) in your FilteringTable called "fName" and "lName", then the above will immediately render as 2 appropriate rows in your table. You may optionally expose the id attribute by having a "Id" field as well. (Note it is "Id" not "id" - an important distinction for filteringTable)
and to make links between names ! (ex : 'id' field of the table => 'toto_id' of the JSON data...
No offense, but I hope this is never a feature, it would lead to some confusing code!! Instead, you can simply rename your attributes. If the json object you have has "toto_id" as an attribute, you can simply assign this value to a new "id" attribute so it shows in your table.
i.e. myObject.id = myObject.toto_id;
filter in top of columns (ex : typing 'toto' in a text field in the top of the column 'name' only shows lines containing 'toto' in their name)
same as filter with lists instead of text field. If the 'name' column is populated with values 'toto', 'titi' and 'tata', a list in top of column 'name' will contain 'toto','titi' and 'tata' values. Selecting one of these values will filter.
Both of these you could implement yourself relatively easily. Place a text field above each column (i.e. above the FilteringTable completely) and have a Javascript method that
1) Stores the existing data store array somewhere (var backupStore = dojo.widget.byId("yourFilteringTableID").store.get() )
2) iterates through all rows (i.e. iterates through all objects in the backing data store) checking the value in the text field against the attribute you wish to filter, and adding the matching objects to a new array
3) Storing the new array in the FilteringTable data store ( dojo.widget.byId("yourFilteringTableID").store.setData(myFilteredArray);
paginating data, with options of pagination : number of elements by page, ability to go to last element, or to page n° x, ability to still use filters and sorting
I recommend implementing your own server-side pagination. Email me (mcurrey --AT-- shaw --DOT-- ca) privately if you need help with this.
All the best,
- Matt
Hi Matt, and thanks for your
Hi Matt, and thanks for your comments.
Of course I know filteringTable can be populated by Json, I use it every day ! What I really want is a way, WITH NO USE OF JAVASCRIPT, i.e. directly typing html code, to associate an id of json data to the id of the dojo table, as explained in the previous message.
What is really great in dojo, and doesn't exists in other javascript toolkits, is the dojo parser which allows to implement widgets using only html code.
Why do I need such a fonctionnality ?
I'm working with Zend framework, and it proposes, with zend_db_table, the ability to find and export in two lines a rowset from my database... e.g :
$rowset = $my_table->find($my_id);
return Zend_Json::encode($rowset);
... Except that it doesn't allow me to associate names. You may say : "you just have to set same names as in your database table". You're right, but for the "Id" field, It is impossible. So, if there is a way to associate names, it would be easier to me. I insist on the fact that this argument has to be given in html code...
For filter and pagination options, I already have coded this by myself. I think it would be a great feature for everybody. No offense, but just realise that if we had to adapt every widget to our needs, we would quickly abandon the official version of dojo for a non-official version which could hardly evolve...
I don't want a server-side pagination. I don't need it, it is not properly working for sorting data, and it is not always safe. I just want client-side pagination.
I know these are my own wishes, and may be only mine... But you asked us our wishes... ;-)
AddOnUnload not working in dojo 0.9rc1 for Firefox
Hi,
I've been testing the first release candidate of 0.9 and I've found that dojo.addOnUnload(object, method) is not working for Firefox/2.0.0.6. I've tested it in IE6 and it's working perfectly, and in my previous nightly build (from 08/03/2007) it was working for both browsers.
Can it be fixed in 0.9?
Thanks
Please report bugs in trac
If you find a bug, please go directly to trac.dojotoolkit.org (login as guest/guest)
FilteringTable with ... and documentation
Hi,
Thanks for the great job you are doing.
I also think that without a advanced datatable widget dojo will not break thru other frameworks like YUI or others.
Features that I would like to be included in this widget are :
- vertically scrollable with fixed header and / or footer
- horizontally scrollable with fixed row headers (single or multiple column fixed)
- multirow headers and / or footers
- single or multiple row selection
- column selection
- cells range selection (see YUI datatable)
- every table element customizable with css rules
- inline editable cells or better the possibility to place a widget in each cell (validationTextBox, ComboBox, CheckBox etc...)
- dnd possibility to move/copy rows from one table to another table/widget/object
- sort and filtering feature
- lazy-loading of data to improve performance for large datasets
- very nice would be to be able to mix the table and a sort of tree to display hierarchical data, with a "+" sign left of the to expand the children rows.
Documentation MUST be improved and working examples added for accessibility and learning easyness, since version 0.4 I spend hours and days searching solutions and making trials for poorly documented features.
Best regards
Roger
FilteringTable, Wizard, FloatingPane,Tree,ModalFloatingPane
My wish list:
FilteringTable, Wizard, FloatingPane,Tree and ModalFloatingPane are the widgets we are currently using.
Thanks,
Yan
MenuBar, MenuBarItem, ToolbarButtonGroup
I am working with the beta 9.0 release and noticed some widgets missing that I find of value, MenuBar, MenuBarItem and ToolbarButtonGroup. These widjets are in 0.4 release. I was porting some code from 0.4 to 0.9 when I noticed them missing. They seem like basic widjets that should be supported. I hope they will make it into 1.0. Does anyone know if they are in the nightly? I guess I will get access and have a look.
Regards,
George
Forum
>Does anyone know if they are in the nightly?
see: http://dojotoolkit.org/forum/dijit-dijit-0-9/dijit-support/horizontal-me...
ColorPicker is needed.
dijit.ColorPalette makes it easy to pick a color up.
On the other hand, it is useless to choose various colors.
So I need a color picker: choose colors by slider or value
like http://developer.yahoo.com/yui/colorpicker/
To implement this, first, you may need to make 2D slider widget.
If you can't, I'll use YUI Library.
Sincerely,
Chishu
here:
http://dojotoolkit.org/forum/dojox-dojox/dojox-development-discussion/do...
not sure if i plan on supporting r g b input values to update the display, but am thinking of a way to getValuesRgb/Hex/Hsv instead ...
Looks like this is
Looks like this is done:
http://download.dojotoolkit.org/release-0.9.0/dojo-release-0.9.0/dojox/w...
Live updated datatable with visual notifications
What I miss is a datatable that has visual notifications every time a cell or row is changed. For example:
- when a cell gets a new value, the cell blinks (200 ms off, 800 ms on, 3 times).
- when a row gets inserted, the row blinks.
- when a row gets deleted, the row becomes 50% transparent (or becomes 50% darker), blinks and then disappears.
- when a row gets another position in the table, it is moved and then the whole row blinks.
The use of this datatable:
- http://scoring.indycar.com/2007/ indycar.com Live Timing & Scoring (uses ext)
- stock exchange grid updating
- ticket and messaging system
Also - to be ahead of other frameworks - a grid with colspan would be a nice option. Setting a colspan is very nice for "reporting tables".
I am specialized in live updating and this is the only thing I really miss. I am trying to connect our connection server (> 100.000 concurrent connections per server) with dijits (via ajax).
The same visual updating would be nice for all dijits, like a textbox.
wow..
Wow, we got a lot of comments. Good to know people are still using dojo :-). It's going to take me some time to read through all of these. Some of the things have already been implemented for 0.9, or scheduled for 1.0, but there are also a lot of other interesting suggestions. I'll try to respond over the next few weeks.
wishlist: treetable
Some sort of treetable would be great.
Please see...
Please see
http://dojotoolkit.org/forum/dijit-dijit-0-9/dijit-support/horizontal-me...
And I hope you never mind my strange English because I'm a Japanese.
Dynamic Tree widget with Dnd
I can't upgrade to 0.9 without that
Widget Wishlist
A long while back, a bunch of folks built a Widget Wishlist on the Dojo wiki:
http://dojo.jot.com/WidgetWishlist
It's pretty good.
Wishlist
Great job guys.
Here are a couple more:
1. Vertical slider - horizontal can have problems when label text gets large (or vertical text labels on horiz slider even).
2. Shuffle control - 2 lists with the <<, <, >, >> and Up, Down buttons to select one or more items from a list and resequence them.
3. Breadcrumb trail - to display a navigation path
4. Train station - to display where you are in a sequence of steps e.g. checkout/booking
5. Content links - it would be nice to select an item on a page and drag it to another item to establish a link between them like in Yahoo pipes. It doesn't have to be as fancy graphically (although that would be nice) but more in a Viso way.
6. Item handles - be able to select an item on the page and have handles appear to drag or resize (vertically and horizontally).
I know the last 2 are more designer type features and may be difficult but relate to inplace and graphical editing and would be super cool.
You may also like to take a look at this link which shows images of items 1 to 4 above and may also give you some other ideas.
http://www.oracle.com/technology/products/adf/adffaces/11/doc/multiproje...
many thx.
Thanks for the awesome
Thanks for the awesome feedback.
Vertical sliders are in 0.9.
I agree that item handles and content links would be awesome and we should totally do them. I've also been thinking about node layout algorithms for general purpose graphing and drawing, but I don't think that'll make 1.0.
Wishlist (more)
One other thing I just remembered that is linked to the last 2 points on the previous comment.
7. Rubberband selection - click and drag to draw a rubber band around a number of screen elements to select them and move as a group.
thx
Be nice to have an option on
Be nice to have an option on the Editor to either use HTML or BBCODE.
Dynamic Tree
The #1 feature we need is a ajax tree that can reload nodedata from dynamic source and from predefined (static) files. We did it with the 4.x release and it works ok (using TreeV3). But for 0.9/1.0 we have to wait for a baseimplementation of such a tree.
No need for DnD and usch things here.
Sortable Elements List
A list of elements that can be reordered using drag'n'drop (like http://wiki.script.aculo.us/scriptaculous/page/print/GhostlySortableDemo)
A Real MenuBar Plz~~
i think the combination use of dropdown button, menuitem and popup menu is not working very well....i ve tried several methods but still cant get it work. Problem encountered including switching between menus and focusing when mouse on over..may be some more....
what reasons causing the menu bar removed in 0.9?? is it becoz of menu bar is only treated as a web app components??
finally replied
Hi everyone. Well it's been 3 months but I finally got a chance to reply to all of these comments. Since this blog post is incredibly long (with all the comments) I decided to make a new post with my response.