I recently had need to submit a web form with file fields via AJAX. The application uses jQuery and was already submitting forms just fine without file fields using the .serialize() method to pass data to a jQuery.ajax() call. That didn’t seem to handle the file fields, though. Searching the internet, I found a solution using the browser built in FormData object.
JQuery UI Draggable and Droppable make it fairly easy to implement dragondrop on a web page. There are some things that are not easy to do with it though. One example is having a droppable accept multiple types of draggables with different responses depending on type, especially when added at different times (for instance, being attached by separate objects/scripts). The way JQuery UI is set up, only one droppable behavior set can be attached to an element, so doing
simply replaces the “.type1” options with the “.type2” options.
In a recent project, I needed multiple draggable types per droppable, so I created an object class to handle adding a new “accept” type and associated events to an element that is already a droppable. I do this using duck punching to overwrite the original event callbacks. The wrapper callback checks the draggable element to see if it matches the new “accept” value. If so, it runs the new callback, otherwise it runs the original callback. Every time a new set of droppable options is applied, a new wrapper callback is created that calls the previous, so that no functionality is lost. Perhaps not as efficient as a single function with an if/switch tree, but that would not be feasible for this use case.
jQuery makes it fairly easy to animate DOM elements. Animating a single-step animation on one or more elements is simple with the call of the animate method. Multi-step animations can be more complex because animations are run asynchronously, meaning that they will start running when called but the script will continue onto the next step before the animation is done. For these, jQuery has the ability to queue steps. jQuery automatically queues multiple steps on a single object and dequeues as each completes, so you don’t have to worry about managing things and setting up callbacks. But for more complex animations where multiple elements are animated at different times or other functionality must be performed after an animation step, there is no automatic queuing.
A common practice for simple queuing is to use the “complete” parameter of the animate method or of other similar asynchronous methods that is a callback to be run when the animation is finished. This works nicely when there are a few steps. It becomes more unwieldy though the more steps you add. That is where queue comes in, allowing for adding of as many steps as you want without having to nest in callback after callback.
The design of the gallery portion of the David Hawkins site I’m working on at Cogneato called for a reflection of the current image below that image. This could have been done by making reflections for each image in an image editor and then adding them to a separate field in the CMS. That would have been a pain and would require (most likely) us to be involved for each image added.
Because of the design of the site, I had to modify the script somewhat to make it work properly. One issue was that I had a border around my images.
We had the day off for Veteran’s Day, so I’ve had some extra free time. I spent part of it doing some of the other Lynda tutorials. I worked on the SEO and JQuery ones. The SEO one is crazy long and it felt like I was making no progress. The JQuery one was about double the length of the Worpress one, but I finally finished it. Yeah! Here is my certificate for that one (Link no longer working).
I already knew most of the basics of JQuery, but the tutorial filled in many blanks for me. It went over all of the main parts and functions of JQuery fairly well.
It also introduced me to JQuery UI. That looks very neat for sure, but the full plugin, with the theme and what not, is something like 312kb. That’s crazy huge for a web site. Some (92kb) of that is images which would only load when needed, but the CSS for the theme is 28kb and the script itself is 192kb. Definitely a good thing that it is so easy to customize what parts you want. I generally try to keep my entire page loads, or at least the home page, under 100kb. That is becoming harder and harder as more images and functionality are expected, but it’s good to keep load times fast.
I took some notes on this one, a lot of notes. It’s really just as a reference for me. I forget the specifics of this stuff very easily and am always having to look it up, even sometimes for things I do frequently. I’m somewhat dependent on my notes. So, if I can figure out how, I will attach them as a text file. No point in adding them directly to this post, they will make it huge. But I’ll have to worry about that later: I have a usability event to go to (Link no longer working).