View Full Version : New blog post coming - see the app here first!

9 Jan 2007, 9:48 AM
New blog post coming soon about the new selector implementation. The app to go along with the post also features the new grid 2 half done (reorder columns, locked columns). MessageBox and QuickTips also in use. :)


The selector results are pretty sick. What do you guys think?

9 Jan 2007, 10:22 AM

What is Dom Query? Is is yui-ext's impl of selectors / xpath?

9 Jan 2007, 10:22 AM

9 Jan 2007, 10:29 AM
The numbers and success % are awesome. Does it work only on XTHML / XML or does it work on html as well?

I take it that the XmlQueryDataModel is going to support use of this for xpath eval.

Great stuff!!

btw does column reordering work with the state manager?

11 Jan 2007, 12:50 AM
It works on HTML and XML. It is the default selector provider in yui-ext now, so you can say:

el.select('div.foo'); // composite of all child elements of div and class foo
el.query('div.foo') // array of raw dom nodes
table.selectChild('tr:nth(2)/td:nth(4)') // you have the td at the 2nd row, 4th cell

This is going to open up a lot of new possibilities for initializing components (such as a TabPanel).

var tp = new Ext.TabPanel('some-el', {
autoTabs: 'div.your-tab-class'

Another very powerful thing is the psuedo classes (e.g. :nth) are very easily plugged in and you can create your own in 2 minutes and use them everywhere.

11 Jan 2007, 1:31 AM
Jack, these numbers are sick. I'm sure the jQuery guys, MochiKit guys, etc. are all going to pick apart your test case, but I don't see it falling apart to scrutiny. I'm excited to read your blog post about the new DomQuery class. Does it support extending only pseudo-classes or other query types too (can't think of a specific example right now, sorry)? Will you include an explanation of how to do that in your blog post?

Also, for those that didn't notice, this benchmark app is using grid2 with the leftmost 3 columns locked. That, combined with the column dragging, and nice touches to the aero theme for grids makes for a really hot looking grid.

11 Jan 2007, 2:16 AM
Just one tiny thing. Can the column draging be constrained to the X axis only? Right now, it follows the mouse down the page. It should only track the mouse's X movements.

11 Jan 2007, 8:12 AM
Why animal? Did you notice you can drop the column on the actual column body as well to move it? Why limit it to the tiny window of the header? If it handles bad drops gracefully, it seems like it makes sense to let them drag it anywhere they want.

11 Jan 2007, 9:06 AM
If they drag left, but inadvertently move down into the body, then it's a "bad drop", and the column heading flies back to its original position?

This isn't how most desktop apps work. The column heading moves left and right in a dead straight line even though the mouse may be travelling up and down a little. It's just better user-feedback to see the column you are moving move right or left without having to be very careful that your mouse doesn't stray up or down a bit.

11 Jan 2007, 11:28 AM
I have to say, I'm very happy that things are moving towards CSS selectors for stuff. It's lovely to be able to write a single line or 3 that applies to 20 different elements.

11 Jan 2007, 4:31 PM
Just a UI feedback: in Grid2, if you use a quicktip on a cell it would be great to have a visual cue that the cell does indeed have a quicktip (and is worth the effort of hovering :) ). I'm sure people are familiar with how Excel does this with cells that have a note attached or are in error - where it displays a little colored triangle in the top corner.

I guess you'd want to invoke this cue (or not) when applying the quicktip. I guess you'd want at least two cue styles (1. error/warning/alert; 2. info/note/comment).

11 Jan 2007, 5:03 PM
This may already by possible via CSS, but it'd be good UI feedback to be able to color the cells in the sorted row independent of the row coloring.

12 Jan 2007, 5:36 AM
All good suggestions, thanks.

I really like the QuickTips marker suggestion. You could apply a css background image to the element that has the tip with a css class. Unfortunately since QuickTips doesn't know an element has a tip until it is moused over, it's not possible for it to automatically add the class.

Animal, I just popped open Outlook 2k7 and I can drag the column anywhere on the screen (even outside outlook) :)

12 Jan 2007, 5:53 AM
Not a big deal! It's coming to something when you can be given a free, highly functional widget, and still be finding fault with it :roll:

It's really amazing, and I'm looking forward to the .40 release!

12 Jan 2007, 2:01 PM
Hi Jack,

just looking your test application i saw a small "rendering" bug on the grid (header)columns, maybe you have allready fix it... i know this is in development :wink:. Hiding the sort icon on columns that have right aligment, firefox(2.0+ext:firebug 1.0b) doesn't re-render the text it self.

You can reproduce it by
1. click on "Loops" for sorting
2. click some other column for sorting, labal "Loops" shows only a part of the text.
(maybe is this only an problem on my machine, IE 6 works fine)

Great Job!!! I'm looking forward for .40 release.

1 Feb 2007, 1:48 PM
I am very impressed with what the grids can do already, but I have been wondering a few things about the design and implementation. (Dang... after writing the following, I looked at the source in the grid 2 page, and lo and behold, it uses tables, so a big reason for my writing this is no longer valid. I'll leave it anyway, because the question remains, why you decided to do certain things. I am looking forward to using it.)

First, I've read through many messages on the forum, and comments in the blog looking for the reasoning behind the use of nested divs and spans instead of tables. The main reason I think tables make sense is that they automatically do the two-dimensional constraining of cells, aligning them in rows and columns, and if you implement those same constraints on the sizes of divs and spans in javascript, that will be expensive with large grids. No other built-in element maintains 2D constraints for you. The autosizing feature of tables that lets you see all the content of cells without worrying about font size and other style changes is also a great simplification.

Anticipating part of your answer (which you hinted at), I agree that tables have issues in various browsers which add to the challenge. But so do divs and spans. Are there problems with tables that you have found to be insurmountable? I always suspect people give up on tables for esthetic reasons, and certainly they have been abused, but they are precisely the right thing to use when you want 2D constraints, I believe.

By the way, to freeze rows and columns while using tables as the underlying rendering elements, it would be nice if the browsers supported that internally (thead might be used for frozen header rows, for example). But it is easy enough to work around that by using separate tables for the frozen and non-frozen parts. Changes in one must be reflected by changes in the other.

Second, I read elsewhere that there is difficulty dealing with the equivalent of colspans and rowspans. These are particularly useful in headers, to support hierarchical rows and columns. I have worked with two major applications that required both hierarchical rows and columns, with many levels of depth. A table implementation would make this easier, I would think.

Third, the way the srollbars are set up, they overlap the frozen (locked) rows and columns. Some applications behave that way, so there is some precident, but it becomes more obviously wrong when you have a small scrollable area with a large scrollbar. Also, consider the possibility of split panels (excel style) with separate scroll bars on each.