type: widget
release: 0.0
status: in planning
documentation: N/A
1 - Description:
A grid is essentially an HTML table that has additional features like re-sizable columns, fixed header (only body scrolls), remote sorting, filtering, search, pagination, direct editing, hierarchical rows, and much more.
In detail, a grid is usually used to connect a backend API that prepares a set of information in JSON or XML form to a 'live' Ajax frontend/table. Therefore, the grid has to support remote sorting, filtering and pagination. At a later state, client side sorting/filtering can be added - this is fairly difficult, since all the logic has to be implemented in the frontend.
Most users also assign actions to the actual information in the grid. In order to make it possible to select a certain row, the grid features a multiselection as you would expect in file managers like Windows Explorer. Using the selection, the grid can show or highlight related action buttons at the right of the row - by default edit and delete, where edit transforms the grid's content into seperate inputs, and delete simply deletes the row with an optional warning. Also supported could be a way to add a new row.
The grid makes heavy use of other widgets and utilities, most noticeably Selectable to make rows keyboard+mouse selectable, Resizable to make the whole grid panel and seperate columns resizable and Menu to create possible toolbars and their associated dropdown menus.
One thing to consider for the grid (and many other future UI plugins) is that HTML 5 provides detailed specs for these widgets that we should seriously consider using as a blueprint for our plugins. If we shared similiar naming and conventions, it will provide a cleaner interface in the future when we all have to support both the HTML 5 version (where available) and the JS-based UI plugin verison on the same site (i.e. use the native HTML 5 if availble, fall back to JS if not supported). The other benefit is that these specs have been refined by a large group of people so they are fairly mature and there may be no need to reinvent the wheel. Thoughts?
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#datagrid
jQuery plug-ins:
http://www.trirand.com/jqgrid/jqgrid.html (ThemeRoller-Ready!)
http://github.com/mleibman/SlickGrid
http://reconstrukt.com/ingrid/
http://www.datatables.net
http://tablesorter.com (was part of early versions of UI, got dropped)
http://flexigrid.info/ (Seems dead)
2 - Visual Design:

3 - Functional Specifications/Requirements:
(Detailed descrition of how the script will be structured: defaults, options, architecture, extensibility, etc.)
Features of the alpha implementation Paul did:
- Uses ui.grid.datamodel.js to fetch JSON data
- Uses ui.selectable.js to make rows multiselectable (and navigable) using keyboard+modifiers+click
- Remote pagination
- Remote sorting (by clicking on column headers)
- Display of total rows
- automatic scroll adjusting while navigating using the keyboard
Details from April grid planning session:
Grid usecases
- Enhance a table with local sorting (ala wiki.jqueryui.com Overview table) - applicable for Progressive Enhancement * (+10 hours)
- Build a CRUD interface to a single table (page, sort, filter, create) aka Spreadsheet * (+20 hours)
- Reporting views (page, sort and filter rows, reorder and filter columns)
- Email client (select rows for archiving, click to open thread - GridTree!) - applicable for Progressive Enhancement * (+30 hours)
- Netflix queue (maybe)
- Checkbox selection
- Dynamic columns - Teacher/Student grades * (+10 hours)
- Calculate values based upon selected columns
- User list - multi-select - show multiple user information (master/details with multiple) * (+25 hours)
- A chart that renders from a data store - with cell editing * (+30 hours)
(example http://dwpe.googlecode.com/svn/trunk/charting/vanilla.html)
- Box selector range of cells (highlight on a chart)
- grid with empty row at bottom for new item creation by entering data into any (already editable) cell. New empty row is created as soon as editing starts in cell. Allows for super-fast item creation with down-arrow and typing in one column
Other usecases
- Live search * (+15 hours)
- Data-bound list
- Autocomplete * (+15 hours)
- Paging (for search results)
- Spreadsheet with arbitrary cells and spreadsheet formulas
- Combobox
- Tree
- Chained Selects
- Image grid, Floated images grid with infite scroll and width resizing
- Coverflow (images)
- Carousel (images)
- iTunes
- Hotel / Travel UI (like kayak.com)
Goals for the Grid
- Modular/Extensible
- Scalable (# of rows - 1,000,000, # of columns - 256)
- Build off of existing markup
- Themable (ThemeRoller ready)
- jQuery UI Widget
- Reuses jQuery UI interactions and jQuery UI widgets
- Accessible (keyboard, ARIA, focus management)
markup/css statics: http://jquery-ui.googlecode.com/svn/branches/labs/grid/tests/static/grid/default.html
<div id="test" data-ui-dataType="currency"></div>
$("#test").sortable();
$("#test").sortable({ dataType: "currency" });
<input type="submit" data-ui-icons.primary="ui-wrench" />
Same as? $(":submit").button({ icons: { primary: "ui-wrench" } });
<table>
<thead>
<tr>
<th data-ui-sort="desc" data-ui-dataType="currency" data-ui-hidden="false">Name</th>
</tr>
[
{ title: "Name", sort: "desc", dataType: "currency", hidden: false, sortable: true, sorted: "desc", sortedIndex: 1 }
]
columns: [
{
id: String
label: String,
dataType: String,
sortable: Boolean
sorted "(asc|desc)",
sortedIndex: Integer,
visible: Boolean
}
]
- Data Model (100 hours)
- Dataset, Column, Item, Field
- Data Model is an object that's instantiated and holds the datastore and element list
- Ability to specify the name of the ID on the table - data-ui-id="MyID"
- Ability to specify the ID on a row data-ui-id="1234"
- Provide _default type
- We need to support multiple elements representing a single "row"
- Initialization
- Init the data
- An array of data
- A string pointing to a URL
- A function with a callback - callback gets passed an array
- DOMElement or jQuery Set - run the extractor functionality
- Need a data model ready event
- Data Extractor
- .datastoreAttributes .columnAttributes (both arrays)
- Snap in new extractors: jQuery.dataStore.extractor.table = function( elem, dataStoreObject ) { // Init columns // Init metadata // Extract row data };
Builtin: _default
- Extractors populate .columns, .data?, and misc metadata properties
- Tables
- Extract table metadata
- Extract header names (IF thead, get columns, IF NO thead, get ths from first, IF NO ths use indices).
- Extract row data - completely up to the extractor
- Lists (or anything else)
- Extract element metadata
- No headers to extract
- Load Table From XML
- Remember that data loaded from server could have null fields
- Figure out a syntax for XML and JSON loaded from the server
dom element --> $(domElement).data("data-row-id") // uuid?
null == do it all
id == do it to single row
array<id> == do it to each id
dom element -> id
array<dom elements> -> array<id>
jquery set -> array<dom elements> -> array<id>
number = row at offset #
number, number = row range from offset to offset
array<number> = selection of items at row numbers
jQuery("#someRow").dataStore("hide");
if ( domElement.data("data-row-id") ) { // Must be of type string not number!
$(this).closest(":datastore").dataStore("hide", domElement.data("data-row-id"));
}
hide
remove
delete (?) sort (?) - should be implemented by other plugins
show
refresh
- Elem store should be populated when data is loaded/refreshed.
Need a way to hook in to the render to post-process
// Example of how .dataStore will store the actual data on an element
$("#display").data({
"elemStore", [ .... ],
"dataStore": refToDataStore,
"viewTemplate": "...."
})
// Attaching a Data Store to a couple data store views
$("ul, #display").dataStore( myDataStore );
// Watching for when a few users are selected in one data store view
$("ul").bind("selected", function(e){
// And updating another data store view with the results
$("#display").dataStore("show", $("ul li:selected"));
});
// When nothing is selected, hide the details data store view
$("ul").bind("unselected", function(e){
$("#display").dataStore("hide");
});
- A way to invalidate the entire data store
.dataStore("remove")
- A way to load chunks of the data store (either from local or from remote) needs URL mapping
Row number is the position in the data set / position in the set on the server
Row ID is a unique identifier (used for editing, saving, etc.)
.addClass("indicator")
// Internally, updates individual rows (merges the two objects for each row)
// Then calls refresh on all the rows (e.g. "refresh", 0, 9)
.dataStore("update", 0, 9, object, {
success / error / timeout
.removeClass("indicator")
//call refresh on other data store view
}) // needs to support array<object>
// or .dataStore("refresh") on other data store view
// Publish some events: updating, updated, update-error
- A way to update existing records
- Communicate changes to a server
- A way to update the rendered view of a record
$("#somerow").dataStore("refresh")
$("table").dataStore("refresh") // refresh elemstore
- URL Mapping
- Use a template (?)
function urlMapper( options ) {
// options.offset
// options.pagesize
// options.columns = [
// { id: "name", label: "Name", sorted: "asc", sortedIndex: 2, filter: "John" },
// ...
// ];
return "http://example.com/?offset={{offset}}&pagesize={{pagesize}}&sort={{column?}}&dir={{dir}}";
}
- Type (i18n/l10n) (30-40 hours)
- Any plugin that uses these should have a 'refresh' to reload the UI controls with the right values.
- View (Number -> String, e.g. 5000 - "5,000")
- Read ("5,000" -> 5000)
- Detect ("5,000" -> "Number")
- Edit (Produce Markup?)
- Trigger an event when the change is complete
- Filter (if it's a date - datepicker)
- Validation
- Types
- Currency
- Number
- Date
- Time
- Combobox (autocomplete - pass in values or pre-population from existing values)
- http://wiki.jqueryui.com/i18n
- http://forum.jquery.com/topic/locale-information-should-be-separated-from-plugins
jQuery.types.aftertoday = {
type: "date",
options: { }
};
- Zero Feature (50-60 hours)
- Creating/populating the titlebar from caption
- Loading data from the table
- Set column width (defaults to auto, have an 'equal' option, and specify width)
- Div around both tables, can support horizontal scrolling
- Set table height (data-ui-height?) can be a pixel or 'auto' (auto expands to full contents)
- If this is not specified, then we should expand height/width (needs investigation)
- Trimming table cell contents to keep them from wrapping
- A way to highlight a column explicitly
- A way to refresh the table or an individual row
- Alignment of columns
- Ability to Show Row # in a column (dynamic column)
- Theming
- Hover Row / Hover Column / Hover Cell
- Striping
- If height is specified, and row body height could have scrollbar
- Selection (80-100 hours)
- UI styling needs more detail (focus / active / selected)
- Merge with existing Selectable functionality into new Selection plugin
- Event for when selection occurs and a data method for accessing all selected items
- Mouse Options:
- Drag and select multiple
- At most one can be selected
- Making a new selection clears any previous selection
- Clicking to select an already selected does not toggle
- Should checkboxes/radios be injected/used for the user to interact with
- Modifier keys
- Shift: Expands continuous selection range
- Meta (Mac-Cmd/Win-Ctrl): Toggles single item without affected other selection(s) where the click without the modifier would
- Keyboard navigation
- Up/Down or Left/Right
- Sorting (20-30 hours)
- Top-level data-ui-sortable="true" on table
- Specify the column types (way to specify types)
- Specified as an array of values
- PE: data-ui-format="currency" vs. data-ui-l10n-format="currency"
- Specify the starting sort direction (desc, asc)
- data-ui-sortdir="desc"
- Enable/Disable Sorting on a particular column
- data-ui-sortable="false"
- Depends upon Type(i18n/l10n) plugin
- Paging (60-80 hours)
- For Ajax-loading
- # of items per page (specified and/or user customizable)
- data-ui-pagesize
- 1 2 3 ... 1234 (links) OR [ 1 ] of 1234 OR select [ 1, 2, 3 ] OR button to load more
- Need to know the total # of records
- data-ui-totalrecords
- Implement with templates
- First / Last Links
- Next / Prev Links
- Need URL mappers - given a page # and a # of records - give us a URL (!)
- Scrolling
- Hit (near-)bottom, load more (alternative to button - just auto-load)
- Show full scrollbar (as if everything was loaded) and dynamically load more
- Clean up old results
- Completely removes need for links or button
- How does expandable rows affect this?
- Publish 'pagination' event (can be return false to stop the user)
- How do you rebuild the UI later on if changes were made?
- Keyboard Navigation
- Page Up / Page Down
- Editing (120 hours)
- Can make column editable="false"
.dataStore("edit"[, ID[, column]]) // How do we specify true or "date"?
.dataStore("cancelEdit"[, ID]) // remove dom nodes from editing, call refresh
// All of these are stored on the data store view
editing = {
"ID1": true,
"ID2": "date"
}
editing = true;
editing = "date";
// Wipe out state on refresh
editing: {}
Check editing state on pagination
.dataStore("update", ID, dataObj?)
Need to specify how frequently to update
- Row-level blur event (focusenter, focusleave)
- Enter says done with row editing, moves to next row - go to first column
- Tab says done with cell editing, moves to next cell
- Click on cell - turns on editing for whole row (or just cell, if only that cell is on)
- Make sure not to conflate selection with triggering editing - use checkboxes for selection when doing editing as well
- Inline Edit Row
- Generate
- Click to Edit Cell
- Entire Table Editing
- Column Editing
- Add New Item POST
- Dialog for adding in an item?
- Will return data item in format we're using (must contain ID)
- Update the items with the new IDs
- Delete Row POST
- Works like update (success / error / timeout)
- On success, remove and refresh
- Reorder Row // Useful, will not work on at first
- Communicate an insertBefore event?
- Event for when column is changed, event for when entire row is done being edited
- Ways of triggering those events (columnchange and rowdone?)
- Do we have a submit button - if not handle enter key
- Inputs, selects can be used in the page to trigger PE editing
- Depends upon l10n plugin
- Theming
- Active Row / Active Cell / Editing Row/Cell / Error Row/Cell
Default: <tr>{{each columns}}<td>{{field this}}</td>{{/each}}</tr>
Custom:
<fieldset>
<legend>${firstname} ${lastname}</legend>
<label>First name: </label>{{field "firstname"}} {{editing "firstname"}}Uppercase!{{/editing}}
<label>Last name: </label>{{field "lastname"}}
</fieldset>
// Note: Names must be exact matches from header names
$("#row5").dataModel("refresh");
name -> StringFilter -> "John"
city -> StringFilter -> "Boston"
date -> StringFilterEdit -> <input type="text" ....>
Need template methods:
- field
- editing
- editable
- Filtering/Searching (40-60 hours)
- data-ui-filter="string|boolean|number|..."
- Would be good to have a way to have an external set of controls which you can use to filter
- Have an extra row with the filter controls
- Need main function to filter, will AND multiple filters whether on single column or multiple columns by default (can be overidden)
- Per column template and filter function definition
- Filter Types:
- text (exact- or like-match), with optional Autocomplete support, based on column content
- boolean (true/false, checkbox or radio button)
- numbers (exact match, greater-then, less-then, range)
- if min or max, or both, are known, offer a slider
- date (exact match, greater-then, less-then, range)
- select (checkboxes for distinct column values - none checked, show everything, otherwise display all checked matches)
- mulit-select, populated with values from the column
[ Select =, <, >, <=>? ]
- Hide/Show Columns for Grid (20 hours)
- data-ui-visibility="hidden" on the column header (Implements aria hidden)
- Gear/button above scrollbar for menu to hide/show columns
- Column Reordering for Grid (20-30 hours)
- Drag and Drop
- Separate data structure for header order
- Column Resizing (30-40 hours)
- Some vertical indicator denoting the edge being dragged
- Only change width on the end of the drag
- Try to use colgroup styling.
#mygrid td.ui-column-name { width: 160px; background-color: #F5F5F5; text-align: right; }
<tr><td class="ui-column-name">My Name</td>
- Column Totals (15 hours)
- Ask server for details?
- Show on selection
- Formulas (15 hours)
- Compute row on update
- Can only be done on static tables when sorting
- Row Grouping (30 hours)
- Need template for the grouping plugin
- A way to specify the label to associate with the value
- Hook to a specific column data-ui-grouping="true"
- Requires the existance of multi-column sorting (sort on group, column)
- Collapsing? Number totals?
- Grid Tree (60-80 hours)
- data-ui-parentid="pid"
- Based upon the filter plugin, select based upon parentid
- Styling a particular column (should probably be specified)
- Requires the existance of multi-column sorting (sort on pid, column)
- Should not use paging with this
- Dynamically insert elements into the right part of the tree when dynamically loaded
ARIA Spec for tree grid http://www.w3.org/TR/wai-aria/roles#treegrid
from Mozilla site: https://wiki.mozilla.org/Accessibility/TreeGrid
http://mleibman.github.com/SlickGrid/examples/example3-editing.html
Why not use another grid?
- Is not modularized or extensible
- Is not written in the UI style
Comparison with other grids
4 - Markup & Style:
4.1 Initial markup examples
(Pre-enhanced HTML markup structure that will be transformed into the final widget. There may be multiple possible HTML markup options per widget: for example, for a slider, radiobuttons, inputs or selects could all be used. )
4.2 Recommended transformed HTML markup
First pass: http://jquery-ui.googlecode.com/svn/branches/labs/grid/tests/static/grid/default.html
4.3 Accessibility recommendation
(Detailed recommendations for ARIA, HTML markup, CSS and javascript that will contribute to universal access and full section 508 accessibility for screen readers, mobile devices and any other devices)
4.4 CSS & Theme
First pass: http://jquery-ui.googlecode.com/svn/branches/labs/grid/tests/static/grid/default.html
5 - Latest version of plugin:
http://jquery-ui.googlecode.com/svn/branches/labs/grid/tests/visual/grid.html
6 - Open issues being discussed
(Use this area to place things that we're hashing out like featuresand options we're not sure we should include, questions about how this fits into UI and relates to other widgets and utilities, known problems, whether features should be broken across multiple releases, etc.)
Comments (34)
Matteo Ligabue said
at 11:32 am on Jan 5, 2009
I really think this should be moved higher in priority.
In real word usage the grid component is central (for instance I can't imagine a simple CRUD application without a grid component.
Richard D. Worth said
at 12:25 pm on Jan 5, 2009
The grid is surely a plugin in high demand. And key for creating a lot of applications, as you mention. One reason it's not higher in priority is not because we don't think it's valuable or important, but because it's complex and we want to do it right. Doing so means depending on some lower-level plugins/utilities that aren't started/finished yet. We'll get there. And in fact, some work is already being done on it in http://jquery-ui.googlecode.com/svn/branches/dev/grid/. The priority we have set should not discourage anyone from doing any work on any plugin. Just a way to answer the questions, "Where is the team focusing the most efforts right now?" "What is most likely to be finished next?" and "Why are you all working on X before/instead of Y?"
Andrew Powell said
at 12:23 pm on Mar 10, 2009
Something else that might be considered is the plugin/widget and parser abilities of tablesorter. http://tablesorter.com. It's a fantastic plugin and allows for some great extensibility. It's flexibility for late-bound sorting and initialization has been key for our uses. (ie. having a serverside script generate a table, and then applying the plugin to the table).
Igor said
at 11:34 pm on Mar 15, 2009
May be we should consider 'content grouping/panel' plugin as another basic component of 'grid/table', since the later, as it seen from the pictures, also has a title bar with custom controls and collapsible content.
Lawrence Pit said
at 1:31 am on Apr 8, 2009
I would say that a jquery ui grid should NOT contain features to draw a footer or header. I think the requirements as stated above should also not include the ability to create toolbars and associated menus, nor should it include pagination. Also the grid should not support remote sorting, filtering and pagination. A grid should also not have any logic about how to transform HTML, XML, JSON data, or whatever else.
All these things should be separate from the grid. The grid widget should concentrate on being a grid and only a grid.
I would therefor give +1 vote to slickgrid, because imo that plugin nails it. It's rendering engine is simply awesome.
Scott González said
at 6:09 am on Apr 8, 2009
@lawrence, whether the logic for those features is implemented inside the grid or in other plugins that the grid takes advantage of, these options totally make sense for a grid. These are all very real and very common use cases for a grid, so to say that none of those details belong in the design for a grid is a bit far-reaching.
Todd Parker said
at 6:54 am on Apr 8, 2009
I agree with Scott G. We need to have the grid do more than just client side sorting or it really isn't a grid, it's a table sorter. Where to draw the line is exactly what this conversation is all about. The grid may have a header and multiple toolbars snap in, but we'll have to figure out how baked in these are or if they are just tested to work in conjunction with a grid.
I think the grid needs to handle the internal scrollbar for the table body (it's very hard to do), maybe draggable column widths and a way to hide/show columns, row striping, maybe tree style first column (like MS Project) to hide/show rows, maybe a sub-row spindown for extra info, client-side search and/or filtering. Basically, taking a regular table and manipulating it's display.
From there, having mechanisms for fetching in a variety of data sources via AJAX for handling larger data sets would allow for pagination, searching, filtering tables that would have too many rows to display as a single html table. Even in these cases, we should engineer this to start with a populated table as much as possible. I hate AJAX apps that serve up an empty div where content will be sent in over the wire, it's terrible for mobile, SEO, and accessibility.
Lawrence Pit said
at 5:37 pm on Apr 8, 2009
@Todd: it seems to me you're assuming a technical solution using tables, which then makes handling the scrollbar very hard indeed. It makes the whole thing dog slow, and therefor you must resort to pagination, etc.
Instead, if you apply incremental or virtual rendering techniques using absolute positioned divs and only show within the viewport those items that need be shown suddenly you can easily handle hundreds of thousands of rows on the client and scroll to the bottom within a few milliseconds. This technique is used by for example Sproutcore and SlickGrid.
Next to all those visual and functional requirements that are mentioned I would root for putting a performance requirement at the top of the priority list.
I would argue that a grid is only the container that contains the scrollbar(s). That's what the grid widget should excel at. Nothing more, nothing less.
All the rest surrounding the grid area are different plugins cq ui widgets imo. Integrating those directly into the grid would just be a distraction.
I think it's unnecessary if the grid had logic about how to fetch data in a variety of ways. That is not the concern of a grid. Instead a grid should expose an easy API that allows manipulation of the data (that for example a pagination plugin could take advantage of).
Separation of concerns would promote innovation imo. Instead of trying to squeeze everything into the grid, just focus on being a grid and promote several other projects that focus on for example being a filtering plugin, a data extraction plugin, a paginator, etc.
Another advantage of separating things out is that you can release a fully functional grid much earlier because you don't need to worry about unpolished pagination, filtering, data retrieval, etc. etc. features. Discussions about all the features for example a filtering plugin should have could take place somewhere else. Let's here focus on the grid only.
Todd Parker said
at 7:15 pm on Apr 8, 2009
@lawrence I like the idea of having the grid be primarily focused on the the core grid interaction with an open and modular API so it can be easily extended. The performance of slickgrid is really impressive too.
My primary concern is that it should be an option to grid-ify a nice, well-structured table for accessibility, SEO and ease of implementation purposes. If you look at the slickgrid examples, it's just a bunch of scripts and an empty div and completely breaks w/o JS. Since we're trying to embrace accessibility and progressive enhancement, starting with a table should be an option. If that was part of the approach, there is a lot of merit in how slickgrid works. Maybe when you talk about a data extractor plugin, you're referring to the idea that this could rip the data from a table and pass it into the grid.
Lawrence Pit said
at 12:00 am on Apr 9, 2009
@Todd A fair concern you raise. I've submitted an HTML file to the slickgrid project which shows an example of progressive enhancement. I didn't change anything within the slickgrid code itself.
It basically does, in an extremely simplified way, what indeed I was referring to as a data extractor plugin: it basically rips the data from the table>tbody>tr's, passes it into the grid, hides the table and shows the grid.
Todd Parker said
at 9:41 am on Apr 9, 2009
@lawrence That's cool that you could in theory start with a table with slickgrid. Do you know how accessible the slickgrid is on a screenreader? I just tried the basic slickgrid example on JAWS and Firevox (a screen reader add in) and the big issue I see with using divs is that they lose any semantic meaning that a screenreader would be need to be useful -- you just hear the value, not it's scope or meaning. I also can't seem to get the keyboard navigation shortcuts to work right in the example.
http://slickgrid.googlecode.com/svn/trunk/example1-simple.html
Maybe there is a way to use ARIA attributes to add back in the descriptive bits to make this div-based approach work on a screenreader, but I'm wary of this approach overall. I'm torn because I really like the performance of the virtual grid approach but think the jQuery UI solution needs to be accessible, both w/o scripts and in the enhanced grid version. For tabular data, I think properly coded tables may be the only way to provide the necessary semantics for screen readers (and SEO and mobile devices...). My personal opinion is that using tons of positioned divs is just not a good technical approach for presenting tabular data, even if it is performant, because the content is tripped of any semantic meaning so it only makes sense visually. For tables with 10,000 rows, maybe you could take the "only render what is in the viewport" approach but use a series of stacked tables instead of divs. It's still a bit semantically broken because they are separate tables, but at least we could provide the necessary context and semantics.
Are there some a11y folks who can weigh in on this? I'm far from an expert, just a concerned party.
Todd Parker said
at 9:41 am on Apr 9, 2009
BTW - Here are a few guidelines for making tabular data accessible that we really should try to respect when building the grid (grabbed from http://jimthatcher.com/webcourse9.htm):
* Use caption element as a title for the data table and and/or use the summary attribute to give a brief overview of the structure of the table.
* And markup all table header cells
o Use the table header element, th, for all header cells and add the scope attribute when that scope is ambiguous (corners).
o Or use td together with the scope to specify header cells
o Or use id attributes on the header cells and the headers attribute on the data cells to explicitly associate header information with data cells. This is essential if there are data cells whose header information is not in the same row and the same column as that cell.
Lawrence Pit said
at 7:21 pm on Apr 9, 2009
Two ago a very interesting article was posted on smashingmagazine going precisely into the details of the difference between table based and div based data: http://www.smashingmagazine.com/2009/04/08/from-table-hell-to-div-hell/.
Benito said
at 5:30 am on Apr 27, 2009
This example is great: http://www.dhtmlx.com/docs/products/dhtmlxGrid/. I'm in love with the search boxes. And the advanced example of frozen columns is awesome.
Todd Parker said
at 11:50 am on Apr 29, 2009
I added this to section 1, but wanted to ask here as a question: should we use the HTML 5 spec for menus as a blueprint for our grid (at least where applicable):
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#datagrid
Mahendra said
at 5:03 am on Jun 15, 2009
We have been working on Grid centric application development for last 4 years+, here are our set of requirements
support for %column width
support for % grid width
Column text should word-wrap if column width is smaller/ or you show complete text in tool-tip
Pagination Support
Filtering Support
Custom Column Rendering
Column Re-size
Keyboard/Mouse Navigation
Text Selection and copy Support
Out of Box good look and feel
Internationalization support
[NICE] column selection / re-arrangement
[NICE] Right Click Menu
Jörn Zaefferer said
at 4:59 am on Jul 8, 2009
We need a default demo with a local datasource for viewing it from SVN, without having to have a PHP backend. I'll look into that.
straps said
at 11:43 pm on Jul 15, 2009
The last version of jqGrid (3.5) integrates jQuery UI natively and is a very powerful grid jQuery plugin
blog: http://www.trirand.com/blog
demos: http://www.trirand.com/jqgrid35/jqgrid.html
Thanks
ArunB said
at 10:05 pm on Aug 13, 2009
It would be good if we can have data filtering as in Microsoft Excel.
Sample screen shot: http://img199.imageshack.us/i/excelfiltering.png/. Filter by color may not be required.
Thanks.
Gavin Engel said
at 8:06 pm on Oct 3, 2009
Please note that Datatables plugin now supports skinning with jQueru UI themes:
http://www.datatables.net/styling/themes/flick
Jason Brumwell said
at 7:51 am on Jan 21, 2010
Any movement with this widget? I checked the linked pages but nothing shows up.
Allan Jardine said
at 2:39 am on Feb 5, 2010
Is there any consideration for using one of the currently available jQuery grid plug-ins as a basis for developing GridTable? As noted in the wiki, there are a number of table 'enhancers' already available, most of them offering a good sub-set, or nearly all, of the features required. So rather than duplicate effort, what would be required from one of the current plug-ins to be considered for inclusion? Should the current plug-in developers continue their work, if (effectively) all jQuery grid interaction will be through GridTable? I write this as the author of DataTables.
Richard D. Worth said
at 7:15 am on Feb 5, 2010
We will certainly use the work of many grid plugins as a starting point for the jQuery UI Grid, but we won't simply include an existing plugin wholesale that doesn't use the UI Widget factory, follow the jQuery UI API and coding standards. Our starting point will be to built a lightweight grid base that can be extended by ourselves and users. Many of the existing grids have already grown beyond such a base, some with functionality built-in, some with extension mechanisms. In addition to being extensible (in a way that works for jQuery UI plugins) the grid needs reuse (not reimplement, wherever possible) existing functionality in jQuery UI, such as drag and drop for resizing and moving columns, selectable for selecting rows, buttons and toolbars, etc. If I had to guess, what we develop will be a clean implementation but borrowing and learning from as many as possible. And it will start with the most core and basic features, letting others mature as extensions until it's determined they are essential and ready to be rolled in.
To really answer your question, what would be required from a current plugin to be jQuery UI ready, we only know so much at this point. We know it would have to meet standards defined here:
http://wiki.jqueryui.com/API
http://wiki.jqueryui.com/Coding-standards
http://wiki.jqueryui.com/Widget-factory
what we don't know is what this initial base set of requirements is, because we haven't gotten to that point in the design yet. I think one of the more fruitful activities would be if someone developed a matrix of all the existing grid plugins that are worth evaluating, and showed what features each has and generally how they do things. That is, how are they designed, and how are they built.
Allan Jardine said
at 5:09 am on Feb 7, 2010
Thanks very much for your reply. I do agree that code reuse from the rest of jQuery UI is a very important factor, and quite correct that consistency must be maintained. At the same time, it is equally good to hear that the development work that the community has put into to these various grid components (kudos to all of them - some a really very impressive!) will not simply disappear!
kpitn said
at 2:51 am on Feb 5, 2010
DataTable is a good plugin, often update and it's not not as complex as jqgrid. And jqgrid is taken a way of making money on their works : http://www.trirand.net/default.aspx
kyprus said
at 12:58 pm on Feb 6, 2010
+1 for Datatables, it's a very powerful and elegant solution
paul irish said
at 2:06 pm on Feb 26, 2010
http://www.jankoatwarpspeed.com/post/2010/02/26/table-ui-patterns.aspx had a few decent thoughts. I'd want to peek it over when we start hacking on this component.
Gavin Engel said
at 7:27 pm on Mar 12, 2010
What chance is there that an existing grid plugin (Datatables, jqGrid, etc) would be used instead of creating a new jQuery UI widget?
Gavin Engel said
at 7:46 pm on Mar 12, 2010
edit: I see the previous comment from Richard D. Worth on 7:15 am on Feb 5, 2010. I suppose I am curious to know if the existing plugins come close to meeting the jQueryUI specs. I am not a plugin developer, so I don't think I can judge how close a plugin comes to the standards of jQueryUI.
Richard D. Worth said
at 2:00 pm on May 7, 2010
Some have been modified to use the jQuery UI CSS Framework (yeah), making them ThemeRoller-ready
As far as I know, none have taken (started?) the much larger step of being built on top of the jQuery UI Widget factory. This is what drives our design and API, that all widgets have
- a create: .pluginname() or .pluginname(options)
- an init: .pluginname() or .pluginname(options) called again after already created
- optional options that can be set on init: .pluginname() or .pluginname([options])
- the same options can be get and set after init, with appropriate side-effects: .pluginname("option", "key") or .pluginname("option", "key", value)
- state (see above): .data("pluginname").options
- a destroy that returns the element to its pre-init state: .pluginname("destroy")
- events that can be handled by passing a function as an option to the eventname option or by .bind()-ing to the event type: .pluginname({ eventname: fn }) or .bind("pluginnameeventname", fn)
- event callbacks are passed two arguments: event, ui: .pluginname({ eventname: function(event, ui) })
- chainable methods: .pluginname("method1").pluginname("method2", "option1", "option2")
- a11y considerations: WAI-ARIA
- testing in all supported browsers: FF2+, IE6+, Safari 3.1+, Opera 9.6+, Chrome
fnagel said
at 4:11 am on Apr 15, 2010
Perhaps you would like to take a look at my widgets sortTables in conformance to WAI ARIA and WCAG 2.0
http://github.com/fnagel/jQuery-Accessible-RIA
Comments and suggestions are very appreciated! Would be great some of my ideas and solution would help the jQuery UI Team.
sergio said
at 12:59 pm on May 7, 2010
how can I participate in building the code for this plugin ?
Richard D. Worth said
at 1:44 pm on May 7, 2010
See my Feb 5 comment above: "I think one of the more fruitful activities would be if someone developed a matrix of all the existing grid plugins that are worth evaluating, and showed what features each has and generally how they do things. That is, how are they designed, and how are they built."
The answer (good or bad) is we're not at the building code phase, we're at the analysis, planning and design phase.
Yanick said
at 3:28 pm on Jun 25, 2010
SmartGWT has powerful widgets backed by datasources... could a grid widget be backed by datasources ? I mean, this wouldn't be a mantory thing, I'm just thinking here that having a Datasource plugin could bind to the Grid widget and sync itself with it through the Grid's public API. Datasources could also be used for other widgets that display data...
You don't have permission to comment on this page.