Add custom trigger property for $tooltip provider

[L42y]

close #131

[L42y]

It's not complete yet, but I wonder if I'm in the right direction to implement it.

I also wonder how to implement different defaults for tooltip and popover, any idea?

[joshdmiller]

@L42y Thanks for taking a stab at this! It's always a good idea to check in before you get too far. I'll add some inline comments to the code as I peruse.

[joshdmiller]

These are only to give the template access to some scope variables; why does the template need to know anything about the triggers?

[joshdmiller]

@pkozlowski-opensource The current way of operating is to assume the same trigger for closing as for opening if a closing trigger wasn't provided to the $tooltip service during directive creation. It would be sensible to extend the same functionality to the trigger attributes. But we could also have something more intelligent:

var hideTriggerDefaults = {
  'click': 'click',
  'mouseenter': 'mouseleave',
  // etc...
};

// ...

closeTrigger = closeTrigger || hideTriggerDefaults[openTrigger] || openTrigger;

@L42y Are you still working on this? I'm not rushing you; just wanting to know if I should leave this PR open. I appreciate your effort! :-)

[L42y]

@joshdmiller sure, still working on it. also thank you for the feedback, you're awesome :-)

[L42y]

I just push a new commit base on your feedback, code review round two :D
Wish I did something useful.

[pkozlowski-opensource]

@L42y would be awesome if you could think of tests that exercise this new functionality. Shouldn't be difficult and we at least need a test showing that you can specify the trigger attribute.

[joshdmiller]

@L42y Very nice! A couple of things:

• I don't think the triggers need to be on the scope; it shouldn't matter too much, but since they are never watched and are only accessed from what's defined in the link, it should be fine to have them as regular variables. The other attributes are on the scope because they're interpolated in a string later on.
• For the tests, we'll want a new describe block. We need to test a couple of things:
  • that triggerShow works
  • that triggerHide works
  • our logic for when triggerHide isn't provided (that's two tests because there are two possibilities)

We don't need to test when neither are provided because the entire rest of the test suite depends on the defaults working properly.

@L42y Again - very groovy, my friend.

[L42y]

I pushed another commit. My previous commits actually broke many things, sorry for that, i didn't run test before i push them.

This new commit still broke the custom placement property, but I can't figure out the reason, wish someone would help me, thank you.

[L42y]

Closing this PR due to no proper implementation, thank you so much for your kind helps, looking forward what else I can do for this awesome project.