hidden columns, handling tab from editable

hidden columns, handling tab from editable

keturnketurn Posts: 18Questions: 0Answers: 0
edited August 2010 in KeyTable
Hey, I've been using DataTables for a few months now, and I'm finally turning my attention to KeyTable. I've identified a few issues I'll need to fix:

1) I'm hiding some columns with CSS. KeyTable doesn't know about that and will let me navigate to hidden columns.

2) In the KeyTable + jeditable demo at http://datatables.net/release-datatables/extras/KeyTable/editing.html , when you are editing a cell and you hit "tab", it follows the document tabindex out of the table entirely (since keycapture is off during editing).

I'll be putting some time in to this over the next week and hopefully I can address these and contribute patches back, but I thought I'd let you know here and see if you had any plans for these or other input.

Also, if I am patching KeyTable, do you have a version control system I should base off of, or just the releases?

Replies

  • allanallan Posts: 54,881Questions: 1Answers: 8,601 Site admin
    Hi keturn,

    Thanks for the feedback!

    1. This is sort of intentional - is there any reason why you aren't using the column visibility options in DataTables? They will remove the elements from the live DOM, and thus not be a problem. However, the view I took with this bit was that if the element is in the DOM it should be treated as such, without needed to do a 'check visibility' look up on every focus.

    2. Good point! It might need a preventDefault in there...

    There is a repository for KeyTable here, which you can fork and work with if you like: http://github.com/DataTables/KeyTable . Based on your other thread, it sounds like KeyTable will need major new revision at some point, so the current release series will mainly be a bug fix one.

    Regards,
    Allan
  • keturnketurn Posts: 18Questions: 0Answers: 0
    My "hide with CSS" approach is from the old "trying to attach the database row ID to the TR without it being visible" problem, although I could fix that by using fnRowCallback instead.
  • keturnketurn Posts: 18Questions: 0Answers: 0
    Okay, I've got a patch up at http://github.com/DataTables/KeyTable/pull/1

    (The new github pull request stuff looks pretty nice.)
  • allanallan Posts: 54,881Questions: 1Answers: 8,601 Site admin
    Hi keturn,

    Very nice - thanks for the patch! I'll have a look over the code shortly and pull it in.

    Regards,
    Allan
  • allanallan Posts: 54,881Questions: 1Answers: 8,601 Site admin
    Hi keturn,

    I've been looking over the code although it's quite a simple little change I'm not 100% clear what is happening! I think there are a number of options for the interaction that could be done:

    1. e.preventDefault() - stop the browser moving the focus anywhere - make the tab key do nothing basically
    2. Have the KeyTable focus move to the next box and the currently editable field lost it's editing ability
    3. What currently happens

    I think I prefer option 2 - although it requires more changes in the demo editing code (since jEditable needs to be told to loose the editing an unhook to the cell), that it does in KeyTable. Indeed the only change needed for KeyTable is to change the first condition in _fnKey to "if ( (_that.block && e.keyCode != 9) || !_bKeyCapture )".

    The change needed to the editing code would be a keypress hook on the input (just after the 'faked' click), which watches for a tab press. When it is caught, then click on the body (simulate a click at least) and remove the jEditable hook on the cell (which I'm not actually sure how to do atm).

    What do you think?

    Regards,
    Allan
  • keturnketurn Posts: 18Questions: 0Answers: 0
    edited September 2010
    The patch is not so different than what you describe. I added checking for the magic value "catch-tabs" for best compatibility (in case there's existing code that uses keys.block = true and *wants* KeyTable to stay out of its tab keys), but the simpler condition "(_that.block && e.keyCode != 9) || !_bKeyCapture )" would satisfy me as well.

    And as long as _fnKey is still running for keyCode === 9, you don't need an additional keypress hook on the editable. _fnKey is already catching that tab press and triggering a blur handler. This other bit of code I added to the example translates that in to something that jeditable handles:

    [code]
    /* Send blur to inputs when KeyTable focus moves. */
    keys.event.blur( null, null, function (nCell) {
    $("input:enabled", nCell).trigger('blur');
    } );
    [/code]

    Simulating a click on the body won't trigger anything in particular with jeditable, as $.click does not trigger $.blur handlers.

    Does that clear things up at all?
This discussion has been closed.