|Language:||English, Spanish, Dutch|
|ePub File Size:||17.62 MB|
|PDF File Size:||13.81 MB|
|Distribution:||Free* [*Sign up for free]|
First and foremost, I want to thank my wife, Sarah, for her love, support, and understanding. Sarah, without you, I never would have succeeded in this endeavor.
I love you with all my heart. Thank you for allowing me the late nights and countless weekends to work toward this dream. You have sacrificed so much of your life taking care of things while I could not, and for that, I do not have the words to express my gratitude. I want to thank Kate and Tony for their understanding that Daddy was not there for the better part of a year.
I hope that as you get older, you will use this as an example of knowing that your dreams are attainable with hard work.
I love you both, and I hope to make up the time that I have missed. I want to thank my family, and that goes to everyone who chipped in and helped with the kids and I do not even know what else, as I worked away on my laptop. All of you gave up countless hours of your own time so that I could write. It humbles me to know I have so much love and support around me. It was reassuring to know that I had that support from them, and it made it less stressful down the home stretch. I want to thank all of my reviewers; no matter how small your contribution, I am grateful for the comments, suggestions, and corrections that I received.
Perry, Stacy Trease, and Chris Wells—all of the work has been much appreciated. I want to thank Simon St. Laurent, my editor, for calming me down when I would start to panic, working with me to give me the time that I needed, and giving me the chance to write this book in the first place. This whole process, being my first and, hopefully, not last, was made almost painless with your help and guidance. I cannot begin to thank you enough. I also want to thank everyone else who helped get this book ready for production.
Thanks to Audrey Doyle for all of the catches, corrections, and changes that have made this so much more readable. Thanks to Rachel Monaghan for all of the work you put into the production of this book, as well as the proofreading.
Thank you, Karen, for giving me such a great animal! And thanks to Ellen, David, Jessamyn, and everyone else who made this book what it is. I have spent more than a year working to see this book become a reality. Everything else in my life took somewhat of a backseat as this happened. I want everyone to know that with the publication of this book comes the completion of one of my life goals—I could not have done it without all of the support that I received.
Ajax Fundamentals Chapters 1 through 6 provide the basic ideas that form the fundamental core of Ajax and building Ajax applications. This part of the book discusses the technologies and foundations that you will need to know before moving on to Ajax within applications and as components. Programming a web page in often meant working with a static page, and maybe a bit of scripting helped manage a form on that page.
That scripting usually came in the form of a Perl or C Common Gateway Interface CGI script, and it handled basic things such as authorization, page counters, search queries, and advertising.
The most dynamic features on the pages were the updating of a counter or time of day, or the changing of an advertising banner when a page reloaded. Applets were briefly the rage for supplying a little chrome to your site, or maybe some animated GIF images to break the monotony of text on the page. Thinking back now, the Web at that time was really a boring place to surf. But look at what we had to use back then. HTML 2.
You pretty much had to develop for Internet Explorer 3. It was a challenging time to make anything that felt truly cool or creative. Since then, tools, standards, hardware technology, and browsers have changed so much that it is difficult to draw a comparison between what the Web was then and what it is today. If you want to jump into implementation, skip ahead to Chapter 4. You can always come back to reflect on how we got here.
Web Page Components When a carpenter goes to work every day, he takes all of his work tools: hammer, saw, screwdrivers, tape measure, and more. Those tools, though, are not what makes a house. What makes a house are the materials that go into it: concrete for a foundation; 3 wood and nails for framing; brick, stone, vinyl, or wood for the exterior—you get the idea.
When we talk about web tools, we are interested in the materials that make up the web pages, web sites, and web applications, not necessarily the tools that are used to build them. Those discussions are best left for other books that can focus more tightly on individual tools. Here, we want to take a closer look at these web tools the components or materials, if you will , and see how these components have changed over the history of the Web—especially since the introduction of Ajax.
Classic Web Components The tools of the classic web page are really more like the wood-framed solid or wattle walls of the Neolithic period. They were crude and simple, serving their purpose but leaving much to be desired. They were a renaissance, though.
Man no longer lived the lifestyle of a nomad following a herd, and instead built permanent settlements to support hunting and farming. In much the same way, the birth of the Web and these classic web pages was a renaissance, giving people communication tools they never had before. Most of the available web browsers were slow to adopt the technology. HTML provided everything in a web page in the classic environment.
Ajax Many more parts go into web sites and web applications today. Ajax is like the materials that go into making a high-rise building.
Finally, XML is the protocol that is used to transfer data back and forth between clients and servers. Case Study You may not think that changing and adding tools would have that much of an impact on how a site functions, but it certainly does. For a case study, I want to turn your attention to a site that actually existed in the classic web environment, and exists now as a changed Ajax web application.
Then there will be no doubt as to just how far the Web has come. The following is a closer look at MapQuest, Inc.
The application then Most people are familiar with MapQuest, seen in Figure , and how it pretty much single-handedly put Internet mapping on the map no pun intended.
MapQuest was Web Page Components 5 launched on February 5, , delivering maps and directions based on user-defined search queries. It has been the primary source for directions and maps on the Web for millions of people ever since well, until Google, at least.
Figure By , it offered traffic reports, travel guides, and Yellow and White Pages as well. How did it deliver all of these services? The same way all other Internet sites did at the time: click on a link or search button, and you were taken to a new page that had to be completely redrawn. The same held true for all of the map navigation.
A change in the zoom factor or a move in any direction yielded a round trip to the server that, upon return, caused the whole page to refresh. What you really need to note about MapQuest—and all web sites in general at the time—is that for every user request for data, the client would need to make a round trip to the server to get information. The client would query the server, and when the server returned with an answer, it was in the form of a completely new page that 6 Chapter 1: Reinventing the Web needed to be loaded into the browser.
Now, this can be an extremely frustrating process, especially when navigating a map or slightly changing query parameters for a driving directions search. And no knock at MapQuest is intended here. After all, this was how everything was done on the Internet back then; it was the only way to do things.
The Web was still in its click-wait-click-wait stage, and nothing about a web page was in any way dynamic. It could take a long time for these pages to reload in the browser—everything on the page had to be loaded again. Figure illustrates the flow of interaction on the Web as it was in The flow of a typical interaction on the Web in The application now In , when Google announced its version of Internet mapping, Google Maps, everything changed both for the mapping industry and for the web development industry in general.
The funny thing was that Google was not using any fancy new technology to create its application. Soon after, all of the major Internet mapping sites had to upgrade, and had to implement all the cool features that Google Maps had, or they would not be able to compete in the long term. MapQuest, shown in Figure , did just that. It is dynamic. This is also the case when you get driving directions and wish to add another stop to your route.
The whole page does not refresh, only the map does, and the new directions are added to the list. The result is a more interactive user experience. Ajax web applications remove the click-wait-click-wait scenario that has plagued the Web for so long.
Now, when you request information, you may still perform other tasks on the page while your request not the whole page loads. Figure shows how Ajax has changed the flow of interaction on a web page. The flow of an Ajax interaction within a web page The addition of Ajax as a tool to use in web applications allows a developer to make user interaction more similar to that of a desktop application. Flickering as a page is loaded after user interaction goes away. The user will perceive everything about the web application as being self-contained.
With this technology a savvy developer can make an application function in virtually the same way, whether on the Web or on the desktop. Modern Web Standards Web standards: these two words evoke different feelings in different people. Some will scoff and roll their eyes, some will get angry and declare the need for them, and some will get on a soapbox and preach to anyone who will listen.
Whatever your view is, it is time to reach a common ground on which everyone can agree. The simple fact is that web standards enable the content of an application to be made available to a much wider range of people and technologies at lower costs and faster development speeds.
Modern Web Standards 9 In the earlier years of the Web, the browser makers were to blame for difficulties in adopting web standards.
Anyone that remembers the days of the 4. No one can really blame Netscape and Microsoft for what they did at the time. Competition was stiff, so why would either of them want to agree on common formats for markup, for example? This is no longer the case. Now developers are to blame for not adopting standards.
Some developers are stuck with the mentality of the s, when browser quirks mode, coding hacks, and other tricks were the only things that allowed code to work in all environments. Now several standards bodies provide the formal standards and technical specifications we all love and hold dear to our hearts. Not only does Ajax use each standard, but also these standards are either the fundamental building blocks of Ajax or may be used in exciting ways with Ajax web applications.
Even after a second version of the standard was released on August 1, , incorporating the errata changes made to that point, it still was not widely adopted. All deprecated features of HTML presentation elements, framesets, etc. Example The development of new applications on the Web, and the use of those applications on different platforms such as mobile and wireless devices, is leading to a greater rate of adoption than when XHTML 1.
Therefore, we will follow this standard in nearly every example in this book see Chapters 20 and 21 for different standards usage. The basket array in the module is kept private and so other parts of our application are unable to directly read it.
It only exists with the module's closure and so the only methods able to access it are those with access to its scope i. Notice how the scoping function in the above basket module is wrapped around all of our functions, which we then call and immediately store the return value of.
This has a number of advantages including: The freedom to have private functions and private members which can only be consumed by our module. As they aren't exposed to the rest of the page only our exported API is , they're considered truly private.
Given that functions are declared normally and are named, it can be easier to show call stacks in a debugger when we're attempting to discover what function s threw an exception. J Crowder has pointed out in the past, it also enables us to return different functions depending on the environment. In the past, I've seen developers use this to perform UA testing in order to provide a code-path in their module specific to IE, but we can easily opt for feature detection these days to achieve a similar goal.
Module Pattern Variations Import mixins This variation of the pattern demonstrates how globals e. This effectively allows us to import them and locally alias them as we wish. This takes as its first argument a dot-separated string such as myObj. Using setObject allows us to set the value of children, creating any of the intermediate objects in the rest of the path passed if they don't already exist.
Oh, and thanks to David Engfer for the joke. Disadvantages The disadvantages of the Module pattern are that as we access both public and private members differently, when we wish to change visibility, we actually have to make changes to each place the member was used.
We also can't access private members in methods that are added to the object at a later point. That said, in many cases the Module pattern is still quite useful and when used correctly, certainly has the potential to improve the structure of our application. Other disadvantages include the inability to create automated unit tests for private members and additional complexity when bugs require hot fixes. It's simply not possible to patch privates.
Instead, one must override all public methods which interact with the buggy privates. Developers can't easily extend privates either, so it's worth remembering privates are not as flexible as they may initially appear.
For further reading on the Module pattern, see Ben Cherry's excellent in-depth article on it. The Revealing Module pattern came about as Heilmann was frustrated with the fact that he had to repeat the name of the main object when we wanted to call one public method from another or access public variables.
The result of his efforts was an updated pattern where we would simply define all of our functions and variables in the private scope and return an anonymous object with pointers to the private functionality we wished to reveal as public.
It also makes it more clear at the end of the module which of our functions and variables may be accessed publicly which eases readability.
Disadvantages A disadvantage of this pattern is that if a private function refers to a public function, that public function can't be overridden if a patch is necessary. This is because the private function will continue to refer to the private implementation and the pattern doesn't apply to public members, only to functions.
Public object members which refer to private variables are also subject to the no-patch rule notes above. As a result of this, modules created with the Revealing Module pattern may be more fragile than those created with the original Module pattern, so care should be taken during usage.
The Singleton Pattern The Singleton pattern is thus known because it restricts instantiation of a class to a single object. Classically, the Singleton pattern can be implemented by creating a class with a method that creates a new instance of the class if one doesn't exist.
In the event of an instance already existing, it simply returns a reference to that object. Singletons differ from static classes or objects as we can delay their initialization, generally because they require some information that may not be available during initialization time. They don't provide a way for code that is unaware of a previous reference to them to easily retrieve them. This is because it is neither the object or "class" that's returned by a Singleton, it's a structure.
When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code. The second of these points refers to a case where we might need code such as: mySingleton. FooSingleton above would be a subclass of BasicSingleton and implement the same interface.
Why is deferring execution considered important for a Singleton? It is important to note the difference between a static instance of a class object and a Singleton: whilst a Singleton can be implemented as a static instance, it can also be constructed lazily, without the need for resources nor memory until this is actually needed.
If we have a static object that can be initialized directly, we need to ensure the code is always executed in the same order e. Both Singletons and static objects are useful but they shouldn't be overused - the same way in which we shouldn't overuse other patterns.
In practice, the Singleton pattern is useful when exactly one object is needed to coordinate others across a system.
They're often an indication that modules in a system are either tightly coupled or that logic is overly spread across multiple parts of a codebase. Singletons can be more difficult to test due to issues ranging from hidden dependencies, the difficulty in creating multiple instances, difficulty in stubbing dependencies and so on.
Miller Medeiros has previously recommended this excellent article on the Singleton and its various issues for further reading as well as the comments to this article, discussing how Singletons can increase tight coupling.