Showing posts with label dom. Show all posts
Showing posts with label dom. Show all posts

Friday, July 4, 2014

Ensure Backbone View Is In The DOM

A nice aspect of Backbone views is that they're guaranteed to have an element. This takes place before the view constructor is called. Even if you don't supply any element details, such as the tag name, the element id — there will always be a div element. However, one thing you have to always remember is the add the element to the DOM. While the view ensures the element gets created, it doesn't ensure that the element is attached to the DOM. This is actually a good thing, because you don't always want to be forced to be working on an element that's in the DOM.

Thursday, July 3, 2014

jQuery: Closest Is Better Than Parent

We know that jQuery is the de-facto DOM traversal tool on the web. Part of what makes this works so well with jQuery is it's chaining ability. You can chain just about everything you need to do as a single statement, without sacrificing readability. There are some scenarios where chaining these traversal operations doesn't work so well. Like when trying to traverse up through the DOM using parent().

Wednesday, June 25, 2014

Determine If Backbone View Has Rendered

I've encountered some tricky situations where I'm not sure if my Backbone view has made it's way into the DOM yet. In other words - how can I tell whether my view has been rendered or not? This situation can lead to some really subtle bugs. For example, some other JavaScript in your view expects the view element in the DOM. But when it's not there, the failure mode is anything but intuitive.

Friday, January 10, 2014

Moving Draggables Within The DOM Tree

The jQuery UI draggable widget let's the user move elements around on the screen. This concept is all the more powerful when used in conjunction with a droppable container. This is essentially a target for the user to drop their draggables. One drawback is that despite the appearance of having been dropped into the new DOM node, this is not the case. The only thing that changes when draggables are moved around on the screen are their positional CSS properties. A lot of the time, it would be nice to have the draggable move not only in presentation properties, but to change it's position in the DOM tree too.

Wednesday, August 12, 2009

jQuery Context

How many times have you wished there was an easier way to find DOM elements in a given HTML document? The jQuery javascript toolkit offers a powerful set of CSS selectors that enable developers to do just that; easily query DOM elements. The heart of the jQuery toolkit relies on these selectors. If you are using jQuery in your javascript applications to manipulate the DOM tree, you probably haven't noticed any performance issues while issuing queries. This is because jQuery is highly optimized.

However, the performance can still be improved. The jQuery() function is most often used to query the entire DOM tree. That is, if you issue a query for a DOM id, the selector is applied to every element in the document. More often than not, there is an opportunity to specify a context. For instance, when issuing a query, the developer may know that the given id exists somewhere within another element. Luckily, this element can be specified as a query context when issuing the query.

The benefit to using the context parameter is that the search for the specified DOM elements is narrowed. Possibly by a significant margin. There is another benefit to using the context parameter. Maintainability. Developers can easily deduce why a given query isn't yielding expected results for instance. Finally, the context can be used pragmatically to affect behavior. Below is an example of how to apply the context parameter to DOM queries using the core jQuery() function.
//Example; jQuery context.

var my_div=jQuery("#my_div");
var my_elements=jQuery(".my_elements", my_div);

Thursday, April 30, 2009

Producing Stable Javascript with jQuery

If one were to view the page source of ten random different web pages, a large percentage, if not all, of those pages would contain some form of javascript. Applications that use the web browser has the delivery medium are using javascript more and more. Of course, the developers creating these pages aren't using javascript just for the sake of it. Javascript is often introduced to a web page that is lacking in a rich, interactive, user experience. In order for any javascript code to effectively change the way the user experiences the web page, the DOM elements that make up the page need to be manipulated. This means that the javascript needs to be able to locate a specific DOM element or search for a set of DOM elements that meet some specified criteria. One we have obtained a DOM element, or a set of DOM elements in our code, we need to perform actions on these elements in order to manipulate them. In the case of a set of DOM elements, this set needs to be iterated while invoking behavior on each element. Using tradition javascript DOM manipulation can lead to nothing short of a nightmare. On top of the messy code, developers have the added burden of making it work on all browsers. Thankfully, the jQuery toolkit helps alleviate some of this madness by providing some consistency.

At the core of jQuery is the jQuery() query function. This function allows developers to execute DOM element quires at any level of complexity. The function can be used to fetch a single DOM element by id, or using other query constraints such as class or attribute to retrieve a set of DOM elements. The result set returned by the jQuery() function is actually another javascript object. Methods may be invoked on this object. The interesting aspect of this is that the invoked behavior is called for each element in the result set, not just the result set object. If the result set contains a single DOM element, the invoked behavior is called for that single element. If the result set contains several DOM elements, the invoked behavior is applied to every element. If the result set contains no elements, the behavior isn't invoked. This is extremely useful because behavior will never be invoked on a non-existent DOM element. No error handling or looping constructs need to be implemented by the developer. jQuery also projects a shorthand $() function for the main jQuery() function. This, however can be hard on the eyes after a while.

If your javascript also employs logic other than manipulating the DOM, jQuery is also powerful in this area. The jQuery() function also accepts javascript arrays. Developers can then invoke the each() function on the result set. This provides a consistent way to iterate through javascript arrays. This is mostly important because trying to get the same javascript array iteration code to work on multiple browsers isn't easy. Why write the cross-browser code when it is already done?