jQuery in Action
Adding new wrapper methods
211
We could easily create another variable to hold it, but there's a lot to be said
for keeping things corralled. Let's store the list as another property on
settings
as follows:
settings.thumbnails = this.filter('img');
Filtering the wrapped set (available via
this
in the method) for only image ele-
ments results in a new wrapped set (containing only
<img>
elements) that we store
in a property of
settings
that we name
thumbnails
.
Another piece of state that we need to keep track of is the current image. We'll
keep track of that by maintaining an index into the list of thumbnails by adding
another property to
another property to
settings
named
current
as follows:
settings.current = 0;
There is one more setup step that we need to take. If we're going to keep track of
which photo is current by keeping track of its index, there will be at least one case
where, given a reference to a thumbnail element, we'll need to know its index.
The easiest way to handle that is to anticipate this need and to add an expando
(custom property) to the thumbnail elements, recording their respective indexes.
We do that with the following statement:
which photo is current by keeping track of its index, there will be at least one case
where, given a reference to a thumbnail element, we'll need to know its index.
The easiest way to handle that is to anticipate this need and to add an expando
(custom property) to the thumbnail elements, recording their respective indexes.
We do that with the following statement:
settings.thumbnails.each(function(n){this.index = n;});
This statement iterates through each of the thumbnail images, adding an
index
property to it that records its order in the list. Now that our initial state is set up,
we're ready to move on to the meat of the plugin.
we're ready to move on to the meat of the plugin.
Wait a minute! State? How can we expect to keep track of state in a local vari-
able within a function that's about to finish executing? Won't the variable and all
our settings go out of scope when the function returns?
our settings go out of scope when the function returns?
In general that might be true, but there is one case where such a variable sticks
around for longer than its usual scope--when it's part of a closure. We've seen clo-
sures before, but if you're still shaky on them, please review the appendix. You
must understand closures not only for completing the implementation of the
Photomatic Plugin but also when creating anything but the most trivial of plugins.
sures before, but if you're still shaky on them, please review the appendix. You
must understand closures not only for completing the implementation of the
Photomatic Plugin but also when creating anything but the most trivial of plugins.
When we think about the job remaining, we realize that we need to attach a
number of event listeners to the controls and elements that we've taken such great
pains to identify to this point. And each listener we define will create a closure
that includes the
pains to identify to this point. And each listener we define will create a closure
that includes the
settings
variable, so we can rest assured that, even though
set-
tings
may appear to be transient, the state that it represents will stick around and
be available to all the listeners that we define.