Non-automatic ordering

johnblythe

Hi there,

I'd asked a question regarding this previously (http://datatables.net/forums/discussion/27932/no-automatic-resorting#latest) but hadn't fully fleshed out what we were going for and didn't pursue continued discussion as other, more pressing items in the queue stole my attention. But I'm back :)

The situation
rows are grouped by type. so items marked for review are grouped, items needing to be worked on, and then the rest that is ready to go. probably some more groupings in the work, too.

The issue
users are disoriented when they work on things. let's say row 1 is flagged bc it's overpriced. they change the price such that it's no longer flagged and is a 'normal' row now (the kind that is at the bottom of the initial ordering). this bumps it all the way to the bottom of the table. that may be several pages later. ti's likely to be, at the least, below their viewport (the DT is in a modal w yScroll)

The setup
i've got Editor and DataTables working together w some custom extensions and the select2 plugin for one of the fields. only two fields, actually, are editable. the product field (select2 of the user's products) and the price per unit field. selecting a product moves the row to either a flagged status (if it's priced too high) or a normal/ready status. repricing the item, if it's already flagged, is likely to move it from flagged to normal/ready.

The hope
we'd like for a user to edit a row—let's say it was a need-to-work-on row that they choose a product for and it's well priced so it's now a normal/ready row—and it stay put until the user does some sort of re-order of their own (if they in fact do). this is more akin to what they'd be accustomed to seeing take place in Excel and thus the UX impetus.

My thoughts
I could do the initial sort before DT or by way of the html-5 attribute type (http://datatables.net/forums/discussion/27606/html5-data-is-being-ignored#latest) and have drawing not happen automatically as they edit, binding the draw() method to some sort of user action (when they go to sort/order a column, filter, some refresh table button, etc.). all of this is to ask you: is that even possible w DT + Editor or is it too major a change to the core functionality of draw() to pursue? if so, any other hacks or workarounds that come to your mind that I could toy with?

thanks for taking the time to read this long post and any thoughts that you can throw into the ring.

best,

allan

Hi,

and it stay put until the user does some sort of re-order of their own

Unfortunately that isn't possible with Editor / DataTables at the moment. A draw will trigger a resort.

I have been toying with the idea of adding a new option to the draw() method (or possibly a new API) that will simple update the display, but without doing a resort or refilter. It isn't available at the moment because the idea of data being out of sequence feels a bit odd to me. However, the new method will be using by paging methods, so it will be available (possibly not in 1.10.8 - I'm not sure yet - I've still to decide how to actually implement it in the public API!) and could be used with a change in Editor.

The other option is to redraw the table so that the changed row is visible in the new paging.

It is something that has been aspect about before, so I can see this being a core feature of Editor (i.e. available in the core).

Allan

johnblythe

Thanks for the quick, if not saddening :'(, response!

This sounds a bit hacky, but what if: have an ID assigned to each row on the initial load/draw that is the what the table sorts by and only updates when the user actually sorts in some manual or explicit fashion? any snares in that idea that jump out to you before i try my hand at it?

allan

Only snare I can think of is I have no idea how that would be implemented :-).

Allan

johnblythe

Lol. Okay then, if you think that then it's definitely not something worth me even beginning to consider :p

Thanks a bunch -

allan

Hi,

I've just committed the change needed in DataTables to provide this ability. If you grab the nightly version it will include this change.

Then in Editor, search for .draw( false ); and replace it with .draw( 'page' );. That will keep the row in the same place until a proper search or order is performed.

i'll look at making that an option in Editor 1.5 rather than needing a code change.

Allan

johnblythe

You are a gentleman and a scholar. And a BAMF. :)

Thanks a ton. Will grab it and look into it today or Monday!

johnblythe

Hey Alan,

Is this something that made it to the latest release(s)?

I'm not even necessarily trying to keep this from happening as I've begun sorting on another column to avoid it. What is particularly annoying to users is that the scrollY jumps back to the top after a row is edited and redrawn instead of the focus staying in place. Any thoughts on that with regards to the above?

Thanks for any info!

johnblythe

hey alan,

one other thought was to use the fixedHeader extension. the table opens up in a modal window, however, and doesn't seem to work with that context's scrollbar, looking rather for the window scroll. is that right?

is there any creative way you can think of to have a fixed header or scrollY (since that offers the same general experience for the user of having headers in view while looking through data) work in a way that doesn't jump the user to the top of the table on an update/draw()?

allan

Yes, the ability to set the type of draw is available through the form-options object - specifically the drawType parameter.

the table opens up in a modal window, however, and doesn't seem to work with that context's scrollbar, looking rather for the window scroll. is that right?

Unfortunately yes, that is correct. FixedHeader currently does not support being displayed in a modal.

Allan