-
Notifications
You must be signed in to change notification settings - Fork 754
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug fix: make config.cache indexation corresponding config.$tbodies #820
Bug fix: make config.cache indexation corresponding config.$tbodies #820
Conversation
The update shows how to deal with unordered JSON data
fyi, you can ignore the whitespace on github as well by adding |
@thezoggy Thank you a lot! Didn't know that feature. |
Hi @prijutme4ty! Thanks for contributing. I have a few issues with the changes so far: Overall
Widget Specific
Honestly, I don't think it's a bad idea to make the indexing match the internal cache; but I would prefer to save big changes like this for Abelt. |
Hi, @Mottie! The only situation which can be broken - if someone had manually iterated cache indices through all tbodies using I've checked and fixed all the widgets in a project that they use |
@Mottie, |
Hey! Yes, I think your solution is a good idea. The reason I hesitate is because I was working on a widget which allows the sorting of tbodies (see #195). In order to make the widget work, it needs values stored in the cache from a target row in the tbody (read more about it in the linked issue). The problem appears when the tbody is a "info-only" tbody - the widget will still allow sorting it, but in that case it would need a slot within the cache to store the target row from the tbody. If we remove that slot, I'll need to find an alternative way of storing the row information for that widget. I just haven't had the time to look into making that widget work, because when a table is full of "info-only" tbodies, the parsers don't get set. So now I need to make the parser detection code public so I can access it from the widget, or just copy over that entire block of code. Here is an example of how the tables could be formatted... the included "sortTbody" widget was written before tablesorter v1.16, so the cache changes are not applied to it. Like I said, I haven't had much time to work on it. |
I got your concerns. It sounds like a big obstacle. |
Well, that's the thing... the cache could be kept the same and the code to modify it adjusted to accommodate supporting The output widget already supports So after all that rambling, what I am essentially saying is we don't necessarily need a separate cache. |
I'm not sure I fully understand your decision. Do you mean that you will store infoOnly tbodies in cache? I don't think it will help sorting of tbodies, because the problem is not only in spans: meaning of cell content in infoOnly tbodies can be quite different. I'd say it's like sorting headers and content together. Anyway a bug should be fixed, so I will make fixes which do not touch internal structure, just get correct indices all over the code. Stay tuned :) |
LOL, wait... I haven't made any final decisions. I appreciate your enthusiasm, but like I said, these are ideas I am thinking about putting into Abelt. It is probably okay to merge these changes into this tablesorter fork... I haven't done it because I there are some conflicts with merging these changes into the build branch. And I was waiting on some feedback about that before I merged it. So, if you would, make your changes in the build branch and I'll merge it. |
Oh, sorry! I've misunderstood you. |
I am currently in to process applying this to master for testing. I'll be testing it against many of the widgets to make sure things since work the same and I'll report back to @Mottie at that point I may attempt to apply it to working and test as well. So stay tuned. |
widgets tested
|
I didn't get through all modules but I have yet to find an issue, I'm going to accept this into working branch I think only you can modify the request to make it against working, once you do I'll merge it. |
@TheSin- made a new pull request, same as this one. |
yup thank you, I'm just resolving the conflicts right now so I can merge it. |
fix little bug in new getElementText
fix little bug in new getElementText
…. ignore info blocks. Remove unused var, rename some local vars into more specific ones;
fd80cc1
to
34567c0
Compare
Merged in #822. Thanks again! |
I've faced a bug with config.cache numeration. It's inconsistent with numeration of config.$tbodies when there're infoOnly tbodies. Namely, c.$tbodies doesn't include info blocks. while c.cache do include empty objects for such tbodies. It caused problems in many widgets (formatter, grouping, chart). I found it when runned formatter on a table with several info-tbody separators and it formatted only a half of a table.
Reason is that widgets typically iterate over config.$tbodies which doesn't include infoOnly blocks but use the same index for caching.
I found you've already done several bugfixes to workaround this behavior (see fixes for #568, #264 and commit 638d070) which became unnecessary now so were reverted in this commit.
$.tablesorter.css.info is now unused (it was used once in guard-condition (js/jquery.tablesorter.widgets.js:1180), check if it's ok to remove that usage) so was removed.
Some variables were renamed along the code, some unused variables were removed.
I've tried to find all occurences of
cache
and verify that this patch will not break anything, but I ask you to inspect whether I considered all the consequences. I still find my knowledge of tablesorter internals as superficial.p.s. I recommend to check difference in code using
git show --ignore-space-change
because removal of unnecessary conditions caused shifting left without any changes of large code blocks inside those conditions.