I am somewhat new to initiating discussion on the Drupal Groups site, and am not quite sure where to bring this up. We have a conflict with two modules we are using, and while I have discovered the problem, I am not quite sure why what is being done is being done, and am not sure where to file a bug (if that is the right thing to do).
We are using both the rotor module and the jquery_plugin module.
This is from the rotor module's rotor.js file:
12 // redefine Cycle's updateActivePagerLink function
13 $.fn.cycle.updateActivePagerLink = function(pager, currSlideIndex){
14 $(pager).find('.rotor-tab').removeClass('selected')
15 .filter('.rotor-tab:eq(' + currSlideIndex + ')').addClass('selected');
16 };
This works fine, unless you include the jquery_plugin module:
jquery_plugin/jquery.cycle.min.js (line 16):
$.fn.cycle.updateActivePagerLink = function(pager,currSlide) {
$(pager).find("a").removeClass("activeSlide").filter("a:eq("+currSlide+")").addClass("activeSlide");};
What I think is happening is that rotor.js is looking for a more specific a.rotor-tab (or literally any element with className='rotor-tab'), and when we have both a jquery_plugin driven module (views-rotor) active on the same page as the rotor.js (countdown), the rotor.js overwrites the expected definition for jquery_plugin (or it is by chance for the ordering, and a race condition to which javascript defines it first and then the second one blows the first away). The problem is that then $(pager.find('.rotor-tab') ends up either null (killing the remainder of the .removeClass on the javascript) or empty and misses the actual 'a' element jquery_plugin is looking for. That and the class names 'selected' and 'activeSlide' differ, and the right style is not applied to the other rotor.
Shouldn't there be a way to localize the permutation of the method to only the module who wants it? Or to make an updateActivePagerLink2 method to use instead? something along this line so the "other" module doesn't get bitten by it? Or does anyone have another suggestion, and then where would that be implemented (my own work-around, a bug submitted to either or both of the other modules, etc)?
Thanks for your help,
Comments
I may have come up with a way
I may have come up with a way to make them both live in harmony with each other:
19 $.fn.cycle.updateActivePagerLinkForRotor = $.fn.cycle.updateActivePagerLink;
20 $.fn.cycle.updateActivePagerLink = function(pager, currSlideIndex){
21 $.fn.cycle.updateActivePagerLinkForRotor(pager, currSlideIndex);
22 $(pager).find('.rotor-tab').removeClass('selected')
23 .filter('.rotor-tab:eq(' + currSlideIndex + ')').addClass('selected');
24 };
Lines 19 and 21 are new code compared to the rest of the redefined function call.
Line 19 stores the original function in a holder, and then line 21 executes the "original" updateActivePagerLink function before performing its own code. In some ways this mimics a base class an an extended class functionality...
The key here is that doing it this way allows the original jquery_plugin definition of updateActivePagerLink to work as it expected, while allowing rotor to operate with its .rotor-tab as it expects...
Now the questions are:
1. Am I headed down the right path with this approach (maybe there's a better way to extend a function in javascript), and
2. Where do I head next to update rotor module or would this apply somewhere else?
Thanks again,