Faster rendering span tip
| Project: | Hovertips and Clicktips |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Hi. i'm using the useful hovertip module. I needed to change some things.
1) I need to render a view list-table, with hovertip in each row. It was very slow, because, for example the targetSelectById (it finds the div with id=X in all html), and the .addclass operations (it modifies html).
Then, when a page is rendered, It still renders some time applying the hovertip code until ready. It is very slow.
For all above, I decided to use the very simple modality
* target termtooltip text
And removed the .addclass calls in involved functions.
2) The second thing was that when I use ajax pager in views (prev, next), it does not apply the hovertip code in the new page elements-list. I modified the views .js code to call hovertipSpanInit each time it updates.
At end of ajax_view.js i put
window.setTimeout(hovertipSpanInit, 1);
Just before until function Drupal.behaviors.ViewsAjaxView ends;
------
Now, It renders a table view of hovertip elements with fast rendering and ajax paging.
Any idea of do it better? The ajax_view.js is a very ugly fix.
Regards.
| Attachment | Size |
|---|---|
| render_fast.patch | 5.76 KB |
#1
Hey thanks for writing about this. I have not worked with pages with too many tips, so the speed issues have not been much trouble. However your patch changes a lot of working code. What I recommend instead is that you write your own variation of hovertipInit. Notice how the code calls hovertipActivate and passes several functions. One function to identify the target elements, another to prepare the tip elements, and yet another to prepare the target. This structure is flexible enough to support both hovertips and clicktips in my demo. So, it should be flexible enough to support the tagging scheme that you want to use, and you could pass a prepare function that does nothing, since no classes need to be added in your case. (The drawback there is that users with javascript disabled may feel they are missing something). In other words, you should be able to write a little bit of your own javascript and make little or no modifications to hovertip.js. That way future changes to this module will not break your site.
Regarding the ajax_view.js change, I'm really not sure whether there is a better way. I'd like to know if anyone comes up with a better idea.