I have been having problems with unpacked gems throwing up warning messages about missing specification files. It looks something like this:
config.gem: Unpacked gem cucumber-0.3.11 in vendor/gems has no specification file. Run 'rake gems:refresh_specs' to fix this.
It has been my experience that running rake gems:refresh_specs doesn't fix the problem at all. What I have found to work though is to add a file named .specification into the root of the unpacked gem. In the case of cucumber, I added this file:
--- !ruby/object:Gem::Specification
name: cucumber
version: !ruby/object:Gem::Version
version: 0.3.11
require_paths:
- lib
platform: ruby
Adjust the gem name and version for any other warnings you get and they should all go away.
Sometimes we may have a generic function that could be triggered from a couple of different places. For example, let's say you have an unordered list with sortable li tags inside and clickable anchor tags that fire the same event to do whatever with the acted on list element.
New with jQuery 1.3 is the closest function, which will find the closest element matching the selector, including self. That means that in the scenario defined above we can have a function that looks like this to handle the event.
[js]function() {
var element = $(this).closest("li");
...
}[/js]
Pretty clean code and it will work as long as the event is triggered anywhere from the target li all the way down through any of its children.
This function is very similar the the parents function that we all know and love. That, of course, will not include the starting element in the search though.
More often than you might think. I have found that writing jQuery extensions is a clean and readable way to write not only plugins, but also application and page specific code. Recently there have been two scenarios where I found it appropriate to write some extensions.
The first is when you are using a plugin in multiple places and have a common way of invoking and interacting with it in your application. I was working with a modal window that was popped from multiple places, so I wrapped the modal plugin in my own extension that knew all the default settings and behaviors for the modal. That way my pages that used it could just invoke my plugin and not have to duplicate all the setup code. This is just an example to illustrate the technique, so please don't bother trying to execute it.
[js](function($) {
$.fn.extend({
openMyModal: function(options) {
//Merge the passed in and default settings, then call the plugin code.
this.popmodal($.extend($.logWorkoutResults.settings, options));
}
});
$.extend({logWorkoutResults: {
settings: {
someSetting: 'blah',
success: function() {
...
}
}
});
})(jQuery);[/js]
So the gist of what we're doing here is providing the common set of settings and function overrides in one place, but still allowing them to be overridden by the caller. The default settings and the passed in settings will be merged and then the plugin will be invoked. You would call it like this:
[js]$(".selector").openMyModal({ someSetting: 'blah blah' });[/js]
Pretty clean and easy to use, yet still easy to override if a certain page needs to change things. You can really go crazy with this, too. Since it is your extension just using a plugin, you can add all sorts of additional functionality.
The other time that it makes a lot of sense to write your own is when you find yourself writing loose functions that take one or more DOM elements as a parameter, or even if your function selects some elements and acts on them. For example, let's look at this plain old function call.
[js]MyPage.myFunction($("div.somestuff"), { parm1: 'value' });[/js]
Instead of having a loose function that depends on being passed a jQuery element, just rewrite your function to extend jQuery and it gets a whole lot cleaner.
[js]$("div.somestuff").myFunction({parm1: 'value'});[/js]The inside of the function is easy to change, too. The old one would have looked like this:
[js]var MyPage = {
myFunction: function(elements, settings) {
elements.each(function() {
//do stuff with 'this'
});
}
};[/js]
But now it will just look like this:
[js](function($) {
$.fn.extend({
myFunction: function(options) {
this.each(function() {
//do something with 'this'
});
}
});
})(jQuery);[/js]
So the implementation code doesn't look that much different, but the calling is a whole lot cleaner and easier to follow. You can just include that extension at the top of your page's js file or where it makes sense.
If you are modifying the DOM on the fly, then you have probably noticed that any event handlers you attach don't work on elements added after page load. Let's say you are making an ajax request and your server is returning an html response that you replace a portion of your DOM with. All the normal event handlers that were applied at page load were not applied to these elements, since they didn't exist at that time, and so now you have a bunch of stuff on the screen that doesn't work.
Your first thought might be to re-add all the event handlers after the DOM update is complete. This would get the job done, but wouldn't be very efficient and would require the event attachment code to be in multiple places.
A better approach would be to use the "live" function introduced in jQuery 1.3 (or the livequery plugin if you are still on 1.2). Instead of applying directly to the element, it captures bubbled events and checks the target element to see if it matches what is being watched. That way, an event on any element that matches the live's selector will have the event fired. The call is basically the same, except you pass in the name type of event to watch for.
[js]$("a.link_to_watch").live('click', function() {});[/js]At the time of writing this post, the event types not supported are blur, focus, mouseover, mouseleave, change, and submit. If you need to attach to those types of events, you will need to use the livequery plugin instead.
