iamceege/tooltipster — pull request #73 by louisameline (2013-10-30 10:38:14+00:00)
Title: Refactored Tooltipster

Ok, it's a small refactoring, but stuff definitely got changed all over the place for the greater good I hope :)
There are definetely enough changes in the internals to justify a merge of this on a seperate branch and ask for people to test before this is merged to master.

@iamceege, since you pushed a few things since I started my work and will not be able to merge, I guess you'll have to just copy-paste the whole thing into 1 commit, disregard it (please don't ! ;) or merge everything by hand again (nightmare). Please let me know if you uncomfortable with some points, as I believe I there is a good reason to everything :) Thanks for your work so far anyway.

So the changes involve :
- code cleaning in the structure (including tooltipster method), choosing clearer variable names, deleted some "var" repetitions. In particular, things have been fixed for tooltips delegated on icons, as that used to be much complicated to know what was going on. Please take a look at the Plugin function to catch it in a glimpse.
- got rid of unnecessery .data() calls (almost all of them) as there was no reason to bind to the DOM in this manner, preferred instance variables
- the update method is now immediate, having seperated the checkInterval and the content update process
- fixed various bindings and unbindings on body
- the provided content and icons can now be jQuery objects with their bindings, the content is now appended and no longer inlined
- fixed a couple bugs for people who would like to use change the plugin name (not sure what the point is however)
- the functionInit behavior is back to how I designed it. @iamceege, please read my comment on my closed pullrequest as I explained why it's the only right choice, in my humble opinion

Behaviors that have changed : don't worry, almost no code-breaking changes for people who use the plugin by its public methods rather than its internals (as they should). Just check my last point, but I hope no one was actually using that feature anyway.
- the tooltip size and position no longer updates on content changes that have been made from the outside without using the update method. I believe that kind of "magic" is not good practice anyway, but autoAnimation parameter may be considered at some point, we'll see
- people who used to bind on the plugin internals like .data() calls on elements should not have done it, please use the proper elementIcon, elementTooltip methods now when you want to build complex interactive tooltips.
- the onlyOne option now defaults to false to avoid unexpected conflicts with non-autoClosing tooltips, see my commit comment on that
- the recently added autoclosing of tooltips when they have a select that changes inside them has been removed, as the plugin should not care about what you put inside them. Please use interactiveAutoClose and the elementTooltip and hide methods to set up your own bindings and behaviors
- the plugin does take of