Using the Engine

The Ajax engine we built in Part II, "Creating and Using the JavaScript Engine," provided us with a reusable and versatile set of JavaScript objects that can be used in any Ajax-enabled project. I personally use the engine for all Ajax interactions I create because the engine provides reusable functionality that can be utilized without alterations in any project, from small websites to large-scale applications. It eliminates the need to rewrite code each time Ajax is used, which saves on development time and ultimately eliminates the need to debug this area of the application based on the fact that it doesn't need to change from one application to the next.

Aside from being a flexible and reusable object, the engine and all the other components and front-end JavaScript logic are encapsulated into objects. Objects are much easier to maintain because all your code is separated and distinguishablethat is, of course, if you create meaningful object names. It also keeps all your code out of the main page, leaving only the objects to import as in other programming languages.

Design Patterns

Design patterns solve common programming problems. On the one hand, they are extremely useful and eliminate the need to produce code work-arounds. On the other hand, they are not always necessary and should not be used unless they are needed to satisfy a specific problem. The most commonly used patterns are the Singleton and the Model View Controller because they help solve structural problems that arise in almost every object-oriented web application.

Using Components

The components we built in Part III, "Creating Reusable Components," provide a few examples of how to build your own custom components and connect them with the Ajax engine and server-side data. With this knowledge, it is possible to move forward building your own custom components to be used in multiple projects and save you development time. Components provide base functionality that can be shared as open source or across multiple applications. The great thing about the components we made in this book is that the design can easily be tweaked based on the fact that the components rely solely on CSS. Relying on CSS is always a solution that will pay off because the look of a component can be completely changed based on different CSS classes and styles that we define, making them very flexible and company specific to follow branding guidelines and so on.

Static Versus Dynamic Responses

Static responses are XML or JSON files that reside on the server, which are not generated based on dynamic data from a database or third-party source. Dynamic responses are the opposite, meaning that they are based on fluid, changing data from a database, for example. Static responses are sometimes the only option you have regardless of the best solution, such as when a client does not have a database or the ability to use a server-side language on her server. In these cases, it is usually more feasible to use XML because if a client is updating the content, it is a much easier language to understand. Static XML or JSON should be used for small single websites that do not need to be updated on a regular basis. XML is also the best cross-application language such as when trying to connect with application APIs or web services.

When creating XML or JSON responses, it is always a best practice to provide the structure with informative names for elements while keeping it as abstract as possible. Keeping the structure abstract is a great way to provide a flexible and reusable response that can easily be parsed by yourself or other developers.

Dynamic responses are the best solution for web applications or even large websites in which a client wants to maintain the content, such as with a content management system.

Error and Feedback Handling

As a developer, I know the time it takes to consider every possible situation in which a message will need to be displayed to a user. Whether it is an error or a successful message that you need to display, it is time-consuming to write the code to handle each and every case. On the bright side, with the reusable JavaScript Dialog object from Chapter 19, "Usability Patterns," we can easily use it instead of an alert, which is what most developers use anyway because of its simplicity. The Dialog object is a good solution for handling all of our front-end messages because it is as simple as writing one line of code in order to use it. Another reason why this object allows us to easily follow best practices is because it keeps our messages consistent in look and feel. Keeping a consistent design for each different type of message will make your application much more intuitive.

Aside from the messages that can occur during the runtime of our applications, we must also be prepared if a user simply does not have the required technologies needed to view our application. Even more important than displaying these messages is making sure that the messages are clear and informative, or simply trying to avoid them in the first place by offering alternatives utilizing the HTTP object we created as an extension of the Ajax engine in Chapter 9, "Extending the Engine." If a message is unavoidable, such as when the user does not have JavaScript, be sure to provide information as to what happened and what to do in order to move forward with using our application. It is important to remember that we are building applications for the users. If they are not capable of understanding how to use our applications, all our hard work goes unusedso always remember the users and work to their advantage.

Application History

The History object we created in Chapter 18, "Interaction Patterns," is very useful in web applications because it can be used in a number of ways to make the user experience much more intuitive. One way in which this object makes the process more intuitive is by providing users with the most recent options they have chosen. Most users have a specific set of needs for using an application, and this object allows them to not have to make as many decisions each time they enter the application. The object we created simply saves the state of specific tasks to a client-side cookie with JavaScript, but ultimately would be much more powerful if it connected to the Ajax engine in order to send the data to the server side and store it in a user preferences or user history table in a database.

Security

When making server-side database connections with Ajax, we leave our database wide open. This is a huge problem because someone could simply make the right HTTP request to our application and wipe away data or overwrite it. This is why the security code in Chapter 23, "Securing Your Application," should be a required step in all your database-enabled Ajax web applications and should never be overlooked.

The purpose of the samples in this book is to provide reusable Ajax-enabled code that can be utilized in any web application. Object-oriented JavaScript, an Ajax engine, and all of the server-side classes are perfect examples of how to accomplish creating code for one application that can be ported to another. From all the JavaScript objects to each XML document, we have created code that is abstracted enough to lend itself to the object-oriented model.