A very smart practice in coding is to test if the function will have the ability to perform in a particular browser. This is especially true in Ajax-based websites as developers have to face constant browser incompatibilities. Objects could easily be a problem when everything is in place for a particular browser but it will just falter since development of the program has not considered other browsers.

Developers will have to use a code something like this:

if ( document.evaluate ) {}

This small value tries to evaluate the function against the browser. Each function is tested with this value which means some parts of the websites may not be tested. If the function is not tested, the function will still go through as long as the browser is compatible with it. Basically, the value is just there to evaluate if the function works in the browser and offer options if the browser will not be possible. This value could even be built in the coding as a function. The coding could also go for the whole webpage through this function:

if ( document.all ) {}

Problem will start to creep in when you start using the latter function. if ( document.all ) will evaluate every function of the coding and see if its compatible with the intended browser. But aside from evaluation, this code is an active function that fills in anything that is not there. This is especially true when you are using a library to develop your application. Automatically, anything that is not in the browser will be supplied by the library. For example, when you are running an application in Opera and the .getElementsByClassName is not there, the document.all will look for the function in the library and install it in the code so that the browser could read the code.

This problem only occurs in non-IE browsers only. The function document.all has the ability to check the function in IE only but on other browser like Opera, document.all could trigger fetching of function in the library to make it work.

This behavior poses an obvious problem to security. Since document.all extracts all the possible functions that are lacking in the browser, it might fetch very sensitive information. If a website is rendered this way, hackers could easily access all possible information. The information might not be displayed on the browser but it has virtually opened itself up for possible hackers.

The function document.all is very easy to implement but could have dire consequences to your Ajax-based application. As always being patient with the coding is one of the key steps to security. The library may have everything that you need but of course your interaction with the library will reveal sensitive information about the application. As much as possible use a smaller function so that this problem will never happen. When you point out a specific function for evaluation, you know which function is evaluated. This prevents from other functions from the library to be extracted and executed for security purposes.

Posted by MixedSoup | No Comments »

If you are starting out in your first Ajax based program, one of the biggest challenges that you have to face is to let your users remember not to hit the back button. Most of the time, Ajax based programs does not like the back button.

Unfortunately, Ajax does not have that functionality in bookmarking the previous page so that it could be reloaded anytime. With this development or some call it a disability; it is quite clear that today’s browsers were built without thinking of the possibility that a back might be extinct one day. It also goes to show that Ajax is way bigger than browsers and Ajax will definitely be going out of the browser one day.

Before we realize those realities, we have to acknowledge the fact that there is still a back button. The functionality of browser will be incomplete without a back button.

Back button function is a very efficient tool for everyone without which we might end up doing the same process all over again instead of just hitting back button to repeat the procedure. A back button should be implemented even in an Ajax based application.

It may sound like a complicated answer to the problem. But the only complication you would face in enabling the back button of your Ajax based application is developing this function for both Mozilla and IE web browser. Each of these browsers have their own configuration so that the back button could be used at any time.

Mozilla:

The first step in enabling the back button is to build a PageLocator function. This code will practically tell the browser where to go. If the webpage is built on different frames, the developer should specify the actual action to perform on previous action of the browser.

However, this code will practically let you go back to the previous webpage but will nevertheless reload. In a regular web-page such as an HTML based site, you can easily go back to the webpage especially the last state of the page before you left. Page locator will just let you go back and it is just like writing the link again in another browser.

To answer this, you have to add another function called setContent. But it does not end there, you have to add # in the parameters so that you will be exactly at where had to go and preserve the last state.

Internet Explorer:

On the other hand, IE needs a little different configuration compared to the Mozilla. In this account, it is highly recommended to use Dojo toolkit as they have a library that offers an easy functionality for an Ajax based function. The back button in this toolkit could be easily used.

Basically this library uses a lot of iFrame so that the webpage and state will be specified. Instead of using # for a more specified function, developers target .src and the load the webpage with the previous state. It is also necessary that a querystring be added that practically imitates the hash functionality.

Posted by MixedSoup | No Comments »

A regular website could easily cache the page’s information. The whole webpage is saved in the temporary folder so that it could be accessed faster the next time user visits the particular page. Unfortunately, this concept is only applied to HTML and other websites where the whole webpage is refreshed whenever something new is added.

Ajax on the other hand, refreshes only part of the page so the natural caching behavior is not applied as it does not detect any general changes on the webpage.

But there is actually a trick on how you can build a caching mechanism in your webpage. To understand this better, we go back to the basic operation of Ajax. Communication that enables changes on a specific part of the webpage requires the URL and the arrays which serve as a target for changes. You can use these elements as an array index that will serve as cached information. Regular caching procedures will follow – your computer will save the information in the temporary folder.

The next time you visit the webpage, instead of requesting the server for the page, you can compare the requested information with the cached data. Of course you have to add “if” function for the system to check the cached information first before proceeding to the server.

Problem comes in when too much information is requested. Even with a strong computer, it is only possible to store a small amount of information. When the temporary folder is “clogged” with temporary information from a particular website, the webpage and the whole browser will slow down and eventually stop functioning because of too much cached information.

To combat that problem an algorithm has to be established. You can use any function you want but while I was browsing through many options, I bumped into the Least Recently Used (LRU). This type of algorithm does exactly what it says in its name: it recognizes the least used cached and automatically deletes them as soon as new information comes in.

But another solution is to increase the cache size. Normally you will have at 5MB of cached information. Just like any HTML based websites you can, easily increase this through a command. The downside of this is your website might run slower that expected because of too much cached information.

Your website will spend too much time checking if there are any matches in the cached section. If you cannot run away from a bigger cache size, consider doubling the link of each cache. Every cache will have forward links as well as backward links. Through this technique which is also called the doubly linked list, you can minimize the temporary stored information.

Caching in Ajax is possible. We had to struggle a little bit in this situation because of browser problem especially on IE but we have found a simple and efficient solution for that. Now, we just have to control the influx of temporary information so that our Ajax based websites will work as efficiently planned.

Posted by MixedSoup | 1 Comment »

RIA (Rich Internet Applications) is highly demanded nowadays. We have to admit that we’re not just content with simple information online. We’re looking for better interaction, faster response, and smarter browsers and programs that could virtually do everything. Various programs have been created to cater to these needs. Just in time for these demands, Ajax has been developed ensuring better interaction and the ability to create a good program without having to rely on bandwidth for data transmission.

Ajax and RIA has been seen to work together however, it’s not necessary that Ajax has to be used for an RIA application. RIA on the other hand doesn’t have to rely on Ajax to create a good application.

So where do you draw the line and what cases should you forget about RIA and concentrate on Ajax? We take a look at some of the situations where an RIA is not necessarily an Ajax based application.

1. Office Applications – Creating simple programs for office applications should always be limited to Ajax but not necessarily an RIA. One great example of office productivity is e-mail. Take for example, Yahoo Mail and Gmail. The latest version of Yahoo Mail has emulated the outlook powered by Adobe AIR while Gmail has used GWT (Google Web Tookit) to develop their e-mail. Since Gmail has limited the information to e-mail without other advertisements and links, it has fared well compared to Yahoo Mail.

2. Online Collaboration Tools – Although office applications is very important to be highly interactive. A great example of this program is the Zoho collaborative tool. You’ll be able to use so many tools to get people to interact with one another. Ajax is used in this project in real time bases but speed is not just the important part, tools is as important with this tools.

As you can see, Ajax is needed in simple programs that rely on speed rather than function while RIA relies on the things that you can do with the program aside from speed of the application. It’s correct to think that Ajax could actually be an add-on to an RIA. However, you have to consider that Ajax also has the ability to create an RIA on its own without using programs that can render RIA (Such as JavaFX and Adobe AIR) without using a single code from Ajax.

Developers are now faced with this challenge: how to render a good looking Ajax without overdoing it. Without experience, developers could still develop a strong Ajax based program but the end result is a program full of functions but has greatly compromised in speed. On the other hand RIA could be rendered with so many flashy functions but has actually forgotten about the essential function or will also slow down the operation of the program.

Balance in RIA and Ajax should be observed. As they go hand in hand, each program should complement each other. A great program doesn’t have to be really flashy; a great program should only answer to the need of the user and exceed them with speed and ease of usage.

Posted by MixedSoup | No Comments »

Time and time again, developers are at awe on any Ajax based website. It’s complexity that matches its efficiency has made the developers and web owners to scramble for knowledge to develop this technique to this hottest web coding today. Although other codes have been thriving, none of them could be compared to JavaScript and the mark-up language XML – the main components of Ajax.

Fortunately, there are individuals who are already proficient in JavaScript long before it even become integrated to Ajax. Because of this, they were able to move ahead of figuring out how Ajax can be built in a simpler manner. Frameworks after frameworks have been released along with the battery of libraries that provide pre-built functions to developers. All the developers need to do is to change some things in the current library.

But that does not mean building an Ajax based website and application is easier in itself. Even with the framework, it is still complicated and could not be handled by any starting developer.

On the other hand, if you are rearing to try your hands to develop an application in tune with today’s hottest development technique here are the simple steps in developing an Ajax based application:

Select the right framework – Let’s face it, you need a framework to build and application. Do not think that the set of libraries will diminish your creativity. There are already hundreds of frameworks out there and each of them has so many functions that most of them might not be even used. There are also frameworks that will help you develop an Ajax based application that do not even require knowledge of JavaScript. Personally, you might end up with a server side if you do not know JavaScript as most of the non-JavaScript frameworks are on that side.

Never overdo the framework – Keep it simple. There are so many functionalities out there and they might have “special considerations” especially for browser compatibility. There are lots of frameworks that could have cross browser so you will not have to stick to one framework and look for answers so that it could be compatible to different browsers. The libraries are already made so you just have to stick to the plane and customize only according to looks.

Not everything should be Ajaxed – Ajax is a very fascinating development technology but it does not have to be used in every part of the webpage. As of this writing, Google’s web crawlers for recognizing web content are not that optimized yet for Ajax. Leave some parts for HTML and meta-tags so that your website will somehow be recognized by web crawlers and be provided with the appropriate ranking.

Test your code – Never, never let your application go without testing it. As of today, there are applications that have been built to test Ajax based website. Some of it could come with a fee to ensure that the application works as planned.

These are only four steps to an Ajax based application. It stresses the importance of using a framework as this provides stability and reusability of the application. Use them and test the so that your application works as planned.

Posted by MixedSoup | No Comments »

DOM is one of the unique functions that made JavaScript what it is today: a great RIA language, becoming the core of Ajax. Understanding Ajax is virtually impossible when you do not have faint information about DOM. DOM which stands for Document Object Model, makes it possible for JavaScript to read HTML and transmit them to a webpage just like a JavaScript should be. With the use of DOM, developers should find it easy to create HTML files and get JavaScript to load them as an RIA. Of course not only HTML could be used with DOM, other functions could also be integrated which makes DOM cater an unlimited power and functionality.

On the other hand, DOM could be very tricky and instead of helping the developers build lightweight functions of Ajax, it would even cripple it. Although DOM could be easily built, without any precaution it would eat up RAM of your client’s PC. DOM will package the HTML and other functions into an object and that means everything will be implemented at one time. Without proper coding, the browser could stop since RAM could not handle everything coming together. Imagine developing an Ajax based application with an HTML so even the dial-up users could easily access your website. If you package the HTML with DOM without precaution, you will end up with absolutely nothing.

Here are some things you need to remember about DOM. First of all, it is easy as it looks but the cost that you have to pay is on the server side. The practical thing you should do is to build the DOM within the server. Coding is very easy but implanting them from the server is the tricky part. However when you are able to do this, you might be able to bypass the problem of coding DOM properly.

The best practice of DOM is not about bypassing the problem. Of course you have to face the fact that developing a program is not about outsmarting the problem but actually coding the function correctly.

We all know DOM is all about the code getElementById. This generic function basically answers all the problems you have in getting the correct HTML function or object. Isolate the elements so that you can identify them one by one. Usually getElementById needs longer coding and could be confusing for your server and will run slower in the client side. But if you isolate the elements, each of them could be directly extracted by DOM enabling the browser access the information faster compared to processing a longer string of commands.

Another simplification that you could do to your function is to build them in a modular function. It is basically similar to building specific command but modular is more about laying out the objects properly. Break up the tagName and className so that each element in the object could be identified faster and easier.

By simplifying your DOM you should be able to get the most out of this function. HTML is a very good addition to JavaScript especially when delivering simple yet useful applications.

Posted by MixedSoup | No Comments »

Undoubtedly, XMLHttpRequest is the most important function in Ajax. With this function, developers could easily transfer XML files from the client to server. XMLHttpRequest can single-handedly transform your application from a simple website to an Ajax based website. Its asynchronous function makes Ajax one of the coolest website and application technique today.

Unfortunately, some developers have used it rather more than they should. Of course when a good thing is overused, it becomes really bad. The case of XMLHttpRequest is no different. When the function is overused it tends to overlap over some of the important things a website should have.

Here are some things that might have been overlooked because of XMLHttpRequest. Remember that the function could still exist if you bring these simple web techniques back.

A Website is a Website – Not an Application

Today’s thrust is more about building web applications rather than simple website. Applications will work on simple functions but when you translate everything online, you get lots of connection problems. When building a website, try to build a good site with minimal application. That way, the website still looks good with its Ajax functionality while keeping its function just like a simple website.

Too Much Information from Interface

Autosuggest is a good thing. In an Ajax based application, you can suggest lots of things to the users as they type in their preferences. Although it might look like a good thing, it is actually a bad thing when it comes to productivity. You have to go with a lot of things before you can actually reach the intended information. To make it clearer, here is an example:

When you type in “a” in the search button, the long list of words related to “a” as a letter would be there.

Although that would not take a lot of time the phrase you are looking for, it is better to delay suggestions a little bit. We are already struggling to know which one is true online and a faulty suggestion box will only get things worst.

Retain Regular Functions

Ajax has the ability to auto-save information making it easy for us to retrieve information in case something happens such as power failure. Some would often do it and make it as a necessity by not adding simple such as saving the information you just entered manually.

On the other hand, auto save will also eliminate the users chance to undo some parts of their work. In short, your function should give users more control of the online features rather than doing it the other way around.

Overdoing XMLHttpRequest is just showing off. The user will just be frustrated of your interface and will probably shy away from your website. If you really want to show what you can do with an XMLHttpRequest tell other developers about it. XMLHttpRequest fosters unlimited functionality – but that does not mean we have to show them all to our users. Just limit them to what could be useful and limit the bragging rights to your fellow developers.

Posted by MixedSoup | No Comments »

Ajax is still going strong and the hype will never go down unless a new and a better technique is coming up. So far, what we have seen are variation of Ajax – FJAX, AHAX and SAJAX. Although they are innovation by themselves, we cannot help but thinking that these innovations happened because of Ajax. We just have to wait a little bit for the next big thing.

For now we have to work a little bit better for Ajax’s development. In this state, the developers still has a lot of things to understand to build a highly efficient Ajax based website. There are so many pitfalls in Ajax and one flaw will mean an unsecured website open for all hackers to exploit.

Here are some of the things that could be left out which will endanger your website:

Changing POST with GET – These two actions are sometimes changed and at first glance, these are just words with almost the same function so it would not do any harm to the application. But take a look at it closely and you will see why GET should be considered red only for very important functions. POST is setting the information for others to see.

On the other hand GET is extracting information from the server while influencing the whole website and application. When you use POST, the information will be there but will never have any influence of the application. This is safer and will leave lesser footprint compared to GET which will influence the whole application.

The temptation to use GET is great since it is really easy to configure with the application. Use POST as much as possible. Although you might have to command almost every function to react to the POST, the security it will do is worth it.

Forgetting about Spiders – There are so many things an Ajax-based could do. But not everything. One of them is the inability to be crawled by search engines. We are not just talking about Google but any search engine will never have the ability to crawl through the text.

If your website is not popular enough, nothing will be searched and the texts will never be crawled. Texts are always an important part of any website so nothing could be crawled when nothing is written – at least in format.

ASP.NET’s Data Type – This situation is unique to ASP.NET framework. This type of framework does not ensure any JavaScript developer that their codes will work in their framework. Unfortunately, ASP.NET cannot or does not want to recognize the data types from JavaScript so you have to work your way around it.

Fortunately, only the really lazy ones will never work around this problem. There are data converters that will aid the developers so that the data will be recognized in ASP.NET. Although it is another step in web development, converters are the only way JavaScript developers could build a website for ASP.NET.

Ajax gives us an infinite possibility of what we can do. But we have to remember that data security is essential for a successful Ajax based website.

Posted by MixedSoup | No Comments »

Personally, one of the simplest yet amazing web tools today is the RSS. This tool could be found everywhere – in blogs, news, podcasts and videos. Users could even configure Google to alert them via RSS with the keywords they prefer. In fact, Google Reader is an elaborate web based program that gathers all the RSS feeds preferred by the user. You do not have to go back and forth to the webpage for update. The news is sent directly to your mail, or to your reader depending on your preferences.

On the other hand, Ajax is an emerging technology that has practically influenced all facets of web technology. Fortunately enough, it has also influenced RSS opening doors to almost infinite possibilities. When a developer is very creative with Ajax, the developer could do so many things and RSS could be recreated to a new life. When we combine RSS and Ajax, we end up with an Ajax based feed. One of cool things you could actually create with Ajax and RSS is a news or blog ticker. This ticker will practically refresh at a pace set by the developer. It will constantly feed the latest news from the chosen RSS by the developer. The developer can place an almost unlimited number of RSS as long as they could be handled by the server.

To build an Ajax based ticker with RSS, you need four things: PHP, Ajax, JavaScript and RSS. Their role in developing an Ajax based ticker will be shown on the following steps:

Step #1: Build a PHP Script for RSS Feed – the first thing you would do of course is to build a function where PHP could fetch the information. The question you would probably ask is: why PHP? PHP is a lightweight code compared to HTML plus it has the ability to cache the RSS file for a certain amount of time. PHP could also effectively transfer the fetched information to JavaScript.

Step #2: Connecting the server and the client using Ajax – transporting information from PHP to JavaScript requires a bridge. This is where Ajax makes its appearance. Using XMLHttpRequest to the server, Ajax should be able to handle data coming from PHP and transmit them to JavaScript. It should be noted that the data transmitted could either be XML or JSON and that should be left to the developer’s preferences. XML could be used and JSON does the same job with the same efficiency. Of course when you are dealing with IE you have to add ActiveXObject to ensure browser compatibility.

Step #3: Getting them all together – to do this you need to configure JavaScript on how it would render the information. That means JavaScript will lay out the data output: when will the ticker change information or how long the new feed will be displayed.

Of course you can modify these by changing color or adding better effects for that “artsy” look in your Ajax based RSS ticker. As long as you are aware of different Ajax functions and RSS capabilities, you can expand your options.

Posted by MixedSoup | No Comments »

At first glance, Ajax is definitely one of the most complicated web techniques out there. The combination of JavaScript, XML and HTML might be just too much for budding developers, literally requiring months of development for a simple Ajax application. Because of its complication, developers have been backing out from Ajax and looking for some alternatives. Fortunately, alternates have come out. One of them is AHAH wherein an HTML version of Ajax is proposed. AHAH has almost the same output but with simpler coding. Another version called FJAX has been circling around the web as it uses Flash to transfer XML files faster with efficient cross browser capabilities.

Another version of Ajax has been proposed and used by some developers. HIJAX has been developed and became a framework following Ajax principles and simplifying it. It is not that revolutionary but its coding is smarter that it is definitely worth a second look.

HIJAX believes in progressive enhancement as the key in developing a highly efficient website. Instead of creating codes and adding texts later, HIJAX takes the other route: take a look at the available texts or web content and apply their own codes, therefore building the website in the process.

But what made HIJAX to be an impressive alternative to Ajax is that it practically does not use any XML at all. Any mark-up is disregarded and even the object handling is not there. Instead of all the complicated things that will be coded for an efficient Ajax implementation, HIJAX passes all the responsibility of executing those codes and functions to an API. The idea of the name (HIJAX) comes from the process of intercepting (Hijacking) forms from server using JavaScript and presenting them in a webpage as a totally brand new website using JavaScript.

There are so many positive implications HIJAX because of its API use. Among them is using the server extensively for its functions. Instead of transferring the functions to the client, the API takes every major function. That means code execution is faster compared to a simple Ajax based website wherein other functions is transferred to client. Another advantage of HIJAX is that JavaScript in client and server side never overlaps. Again, thanks to an API, HIJAX is already a set of framework. Everything is already loaded in the server and at the same time, the information is properly streamlined in client-side JavaScript.

To properly execute the HIJAX, it requires an architectural format for proper support. For HIJAX to work everything has to be modular or else it will just defeat the purpose of building simpler Ajax. HIJAX could be implemented within the modular environment since it does not have that extensive coding requirement. API works in a very modular behavior so it could be easily integrated within that architecture. A great example for this is in developing website, web-developers have to build each function separately and join them all together through an API.

HIJAX is a very smart alternate to Ajax. When maximized, it can assure performances just like, or even more than an Ajax based website.

Posted by MixedSoup | No Comments »