View Full Version : Ext.ux.grid.DisableRow

12 Dec 2008, 1:04 PM
I have created a plugin that provides a simple solution to disable/enable rows within a grid. Any disabled rows are visually apparent and "theme-safe."

The following methods get added to the grid:

The id parameter is the record id of the row to disable/enable

Example usage:

var grid = new Ext.grid.EditorGrid({plugins:new Ext.ux.grid.DisableRow(), ...})
var record = grid.getStore().getAt(0);
var id = record.id;
//applies load mask to row and prevents any further selection.
//removes the existing load mask and allows for row selection.
//determine if a row is disabled.
var isDisabled = grid.isRowDisabled(id);
Known issues:
* When config option preventSelection is true, using the cursor to vertically navigate rows in the grid will stop if it encounters a disabled row.

Please refer to the UX repo for latest code changes and better docs. I will try to keep this post current as well.

Version history:
5/19/9: v0.6 Fix for Ext 3.0 compatibility
1/12/9: v0.5 Fix bug to prevent conflicts between multiple grids.
12/16/8: v0.4
12/15/8: v0.3
12/12/8: v0.1 Alpha release

12 Dec 2008, 8:11 PM
Please Demo!

13 Dec 2008, 7:06 AM
Great plugin.
I'm planning to develop similar kind of plugin for myself. Thank you very much.

13 Dec 2008, 8:26 AM
As far as your known issue when encoutering disabled rows. If you haven't checked it yet, you might look at the "tasks" example. If you check first column it "disables" the row (giving visual crossed out text, etc. appearance). Anyway, if you arrow up/down it doesn't have the problem you mention.

14 Dec 2008, 3:10 AM
great guy
thanks very much

15 Dec 2008, 8:34 AM
Thanks mjlecomte for the tip. I checked the "tasks" and found that their approach uses css to apply appearance changes. Obviously css is a reliable approach but I was attempting to avoid the need for users to include css simply to make use of the plugin. That's why I designed the plugin to utilize masks.

I will have to play with this more.

15 Dec 2008, 9:02 AM
Well you could make your js code create the css then?


15 Dec 2008, 9:42 AM
That is very true. You make lots of good points but I finally remembered my main reason for going with masks. CSS is great but if I start changing the bg color to dark grey for example, that is not going to be cross-compatible with multiple themes. I am not sure at this time if text strike-thru will be adequate.

Ultimately, I will see how it plays out with my users and possibly reconsider using CSS instead.

On a side note, I added a config option so that disabled rows can still be selected. In this case, the arrow key bug is no longer an issue. However, in my implementation, I don't want the users able to select so I will pursue this further.

Thanks for your ideas :)

15 Dec 2008, 10:02 AM
I didn't know the mask varied by theme. Only other thought I'll add is that the class I pointed you at has lookup capabilities. So you could look up the mask from that theme and then use it's properties to create your css (so then it's based on the underlying theme).

16 Dec 2008, 7:03 AM
Most of the masks don't vary per theme because the author has chosen not to override. The slick theme is the only one I know of off hand.

I have not used lookup capabilities before like you mention so I am certainly interested in checking that out more. Thanks!