[Javascript] Organizing onload events
Paul Novitski
paul at juniperwebcraft.com
Sat Sep 23 01:04:28 CDT 2006
At 9/22/2006 08:06 AM, Triche Osborne wrote:
>The more I use unobtrusive methods, the longer my external onload
>script gets and the more often I run into situations where I have
>events that are only required for given pages. Is it standard
>practice to include all of these event attachments in a single file
>which is loaded for every page, regardless of whether the page needs
>the script (and the overhead), or do you tailor the scripts to a
>given page or section?
> Also, what of scripts that require arguments for the
> functions called by the attached events? Example: an optional popup
> function that requires the pathname, width and height of the image
> it is to display. Since I'm often creating these pages via PHP and
> want to keep them as simple as possible for the end-user to style,
> I've thought of assigning a class="popup" and coded ID to the
> thumbnail (something like id="img12345678-300-400").
> This seems awkward, but so does writing out an associative
> multi-dim array for the page's affected elements. (Since the event
> may or may not need to be attached, depending on whether there is
> an enlargement available, I can't just grab all IMG children within
> the item DIVs.)
Hi Triche,
This is a really great question. and I hope the responses reflect the
richness of the topic.
One of the cool things about javascript, like PHP and some other
scripting languages, is that you can test whether a function already
exists -- if (!jsDoSomething) -- and load it as needed, analagous to
DLL architecture. I imagine this would only be practical when the
optional functions were quite large, to justify the necessarily long
time it takes to load anything of any size from an internet server,
but the mechanism is there for when we need it.
The primary trade-off seems to concern cache: if you can tolerate a
long initial load, then the big js file is in cache and won't be
loaded again (until the user clears their cache or explicitly reloads
the browser content). If you break your script down into many
smaller parts and load them as needed, then you distribute the
response time lag more evenly over the experience of browsing the
site. Which way you go on any given project will depend on a dozen
variables, including your expectation of how long (for how many
page-views) an average user is likely to stay and how big "big" is,
even on dial-up.
With regard to your suggestion of img id="img12345678-300-400" you
should remain aware of the relationship between markup and behavior
and of your presumed desire to separate the two. The more details
you hard-code into your markup, the less separable it is from your
script. I'd recommend writing generic markup with ids & classes and
generic behavior in javascript, then joining them together with
datasets that contain the specifics. That way you are much more
likely to be able to modify the markup or the behavior or the data
without necessarily having to tweak all three at once. Project
management will lighten accordingly.
Regards,
Paul
More information about the Javascript
mailing list