Web Development and Design | Tutorial for Java, PHP, HTML, Javascript: jquery-cdn

Web Development and Design | Tutorial for Java, PHP, HTML, Javascript: jquery-cdn
Showing posts with label jquery-cdn. Show all posts
Showing posts with label jquery-cdn. Show all posts

JAVA SCRIPT - Safely Combining Several Libraries in Your Applications

 Safely Combining Several Libraries in Your Applications


Problem

You want to incorporate more than one external library, as well as your own, into one application without each stepping all over the others.

Solution

The safest approach for using multiple libraries is to pick ones that are all based on the same framework, such as using only libraries based on jQuery, the framework used in earlier recipes. 

If that strategy doesn’t work, make sure the libraries all use good programming practices, and none are overriding functionality or event handling provided by the others.

EXPLAIN

Regardless of library purpose, there are fundamental rules governing the behavior of libraries that must be followed. Well-designed libraries do not do things like this:


window.onload=function() {...}


I use the DOM Level 0 window.onload event handler with some of the examples in the book because it’s quick, simple, and doesn’t add a lot of code to the sample.

However, if you have one library that uses the old DOM Level 0 event handling, it overwrites the event capturing utilized by the other libraries and your own application.

Well-designed libraries don’t use DOM Level 0 event handling. Well-designed libraries also namespace all of their functionality. You won’t find the following in a well-defined library:


function foo() { ... }
function bar() { ... }
Each function like this ends up in the global space, which increases the likelihood of clashes with other libraries, and your own applications. Well-designed libraries typically use an anonymous function, ensuring no clash with whatever is exposed to the global space:
 var root = this;
 ...
 if (typeof define === 'function' && define.amd) {
 define('underscore', [], function() {
 return _;
 });
 }
}).call(this);


A library that plays well with other libraries and applications will not extend existing objects via the prototype object. Yes, I know it’s a wonderful way of extending objects, and fundamental to JavaScript, but you can’t control one library from overriding another if both are extending the prototype property for the same object.

Besides, if the frame‐ work and external libraries you use don’t extend existing objects via the prototype, this leaves you free to play in your application. Come to that, library builders should never assume that their library is the only one used in a project.

Well-designed libraries provide event hooks so that you can hook into the library at the points where it performs a major action. the jQuery plug-in described in the solution provided event handler hooks you can use to provide your own func‐ tionality before or after the plug-in’s validation routine.

Well-designed libraries provide good documentation of all of the publicly exposed bits, including methods, properties, and events. You shouldn’t have to guess how to use the library, or examine minute portions of the code, in order to figure out what you need to do.

Well-designed libraries are thoroughly tested, and provide a way to report bugs and view existing bugs. Test code should be accessible wherever it’s hosted. If there’s a major security problem with an existing library, you need to know about it. If there are minor bugs, you need to know about these, too.


Well-designed libraries provide nonminified, original source code. This isn’t essential —just helpful, and something I look for in a library. It goes without saying that a good library is one actively maintained, but it can’t hurt to repeat this assertion.

An even better library is one that’s open sourced, and maintained by a community of users, who hopefully play well together—or is one you can maintain on your own, if the original maintainer can no longer do so. To summarize:

• A good library does not use DOM Level 0 event handling.
• A well-defined library uses an anonymous function to wrap its functionality and doesn’t pollute the global namespace.
• A well-defined library introduces few global objects.
• Libraries that play well with others provide event hooks. Well-behaved libraries also don’t extend existing objects via the prototype property.
• Solid libraries are well-tested, and provide these tests as deliverables.
• Stable libraries are actively maintained, and preferably, open sourced.
• Secure libraries provide documentation of known bugs and problems, and a way to report on any bugs and problems you find.
• Usable libraries are well-documented. Bandwidth-friendly libraries are optimized and compressed, though you can always compress the library yourself.
• Confident libraries aren’t built on the assumption that no other library will be used.

For the most part, you should be able to find what you need and have it work with your preferred framework. Be cautious if a library requires you to add a new framework, that needs to coexist with another framework. However, most well-built framework libraries could work with others.

As an example of framework coexistence, if you use jQuery, you can use another frame‐ work library, such as Underscore or Mootools. The use of global namespaces should prevent name clashes. The only exception to the namespace rule is the dollar sign ($) function, which can be used in other libraries.

You can override the $ by adding the following, after all the libraries have been loaded:

var $j = jQuery.noConflict();

Once you add this code, instead of:

$("#elem").fadeOut('slow');

use :

$j("#elem").fadeOut('slow');

You can use most well-made framework libraries together, but there is tremendous overlap in functionality between the libraries, and this overlap in functionality comes with a cost: bandwidth to download the libraries.

Try to avoid using more than one framework library at a time. Find the one you like, and be prepared to commit to it for some time to come.

JAVA SCRIPT - Using an External Library: Building on the jQuery Framework

Using an External Library: Building on the jQuery Framework 


Problem

You want to create application-specific libraries without having to create your own li‐ brary of reusable routines.

Solution

Use one of the JavaScript libraries, such as jQuery or Underscore, to provide the basic functionality you need, but isolate the use so that you can swap libraries if needed.

EXPLAIN

There are good reasons for using an existing JavaScript library such as jQuery. One is that the code has been robustly tested by several people. Another is that you can tap into a community of support when you run into problems in your applications. jQuery is also extensible, with a wealth of plugins you can incorporate, as well as the ability to create your own. 

Then there’s the time-saving aspect, as jQuery takes over managing the tedious bits of your application. I’m focusing primarily on jQuery because it is the library incorporated into most of the applications I use. It’s also small, specific, modular, and uncomplicated. 

However, there are other good general-purpose and extensible libraries, depending on your needs and preferences.

To use jQuery, include a link to the library before providing links to your own or other, secondary libraries. If using the CDN, use the following:


<script src="//code.jquery.com/jquery-2.1.1.min.js"></script>
A basic starting page that jQuery provides is the following, where the jQuery script is
downloaded, and included in the web page’s body:
<!doctype html>
<html>
<head>
 <meta charset="utf-8" />
 <title>Demo</title>
</head>
<body>
 <script src="jquery.js"></script>
 <script>
 // Your code goes here.
 </script>
</body>
</html>


If you are placing the scripting block in the body, consider putting it at the end, making it easier to discover. There are several application-specific libraries that are dependent on jQuery, so you may want to check if they provide it as part of their own installation.

One aspect of jQuery that differs from most of the examples in this book is that jQuery’s starting point for script is not window.onload, as used for many applications. Instead, the jQuery library provides a page start routine that waits for DOM elements to be loaded, but does not wait for images or other media to finish loading. This beginning point is called the ready event, and looks like the following:

$(document).ready(function() {
...
});

The code snippet demonstrates a couple of other things about jQuery. First, notice the dollar sign element reference: $(document). In jQuery, the dollar sign ($) is a reference to the main jQuery class, and acts as a selector for all element access in the application. If you’re working with jQuery, use the jQuery selector rather than your own element access, because the jQuery selector comes with prepackaged functionality essential for jQuery to operate successfully.

The syntax you use when querying for page elements is the same as the syntax for the querySelector() and querySelectorAll() methods, described in Chapter 5. It’s based on CSS selector syntax for accessing a named element, such as the following:

#divOne{
 color: red;
}

Using jQuery to access a div element with an id of divOne looks like this:

$undefined"#divOne").clickundefinedfunctionundefined) {
 console.logundefined"element clicked");
});

This code snippet returns a reference to the div element identified by divOne, and then attaches a function to the element’s onclick event handler that prints out a message. The code also demonstrates another fundamental aspect of jQuery—it makes heavy use of method chaining. Method chaining is a way of appending methods one to another. In the code, instead of returning a reference to the div element and then attaching the event handler function to it, you attach the event handler directly to the element request.

There is extensive documentation and tutorials on using jQuery, so I’ll leave any further exploration of jQuery for an off-book exercise. However, I did want to cover one im‐ portant aspect of using jQuery—or any framework library with your own applications. The key to making these work now and in the future is to wrap the library use in such a way that you can swap one library out for another, without having to recode your applications—or, at least, minimize the amount of recoding you would have to do. Instead of using the jQuery ready event, create your own so you don’t build a higherlevel dependency on jQuery.

Instead of using jQuery methods directly in your business logic, use your own objects and methods, and call the jQuery methods within these. By providing a layer of abstraction between the implementation of your application’s busi‐ ness logic and the external framework library, if someday you stumble upon Frew, the Wonder Library,

you can swap out jQuery (or another library or framework) and build on Frew. When I wrote the first edition of the JavaScript Cookbook, the big libraries at the time were Prototype.JS and jQuery. Since then, Prototype.JS hasn’t been updated since 2012. This is why you want to isolate which library you use: if it’s no longer being supported, you can swap to another if necessary. It may seem like jQuery will be around forever, but things change.

Of course, some frameworks really do require a commitment, so if you go with this approach, make sure that your choice has an active community and lively support.