Today everyone talks about Web 2.0. But while the idea of a collective intelligence, implied here by the term’s inventor Tim O’Reily remains an object of trivial speculations, it is obvious that the World Wide Web is changing. Web applications are increasingly approaching the level of functionality, which is usually found only in desktop applications. And as this trend is gaining momentum, we can already witness the dawn of a new era brought about by a novel kind of web applications – Rich Internet Applications (IRA). At the same time, the popularity of terms like Web 2.0 and RIA makes developers use them as an attractive label on their products, without actually understanding the meaning behind those notions. So what does RIA mean, eventually?

The term Rich Internet Applications (RIA) was first mentioned in Macromedia’s promotional materials in March 2002. By this the company’s managers wanted to point out that the well-known Flash technology is not limited to creating attractive visual web-elements, but can also be used to develop fully functional web-based business applications. Apart from providing user with data, static pages of older-type sites are much less flexible in terms of user-data interaction compared to desktop applications. Every time you request additional data (navigate the site) or upload data to server the pages have to reload. This is often inconvenient and, above all, can compromise security because of the possibility of data loss (say, due to a lost server connection). Yet this is exactly the way Web 1.0 works. Every time you type URL or save data in a web form, server receives instructions which it then uses to form a page you see next. With RIA, there’s no need to reload pages. As you click to receive additional data or send data to server, the latter receives corresponding instructions and uploads the results onto the page. The application receives server’s response and changes accordingly. For example, if you browse an internet catalogue of an older type, every time you hit the button “next 20 items” you will have to wait for the page to reload and for a new page to shape. With a RIA-based site, you can request items 50 to 80 or all items in a specified price range on the same page, and with every new query only the list of items will be updated.

Today RIA can be developed with the help of AJAX, Adobe Flex, Windows Presentation Foundation, Flash, Java-applets, Java and some declarative languages – such as XUL and MXML. Of all these tools only AJAX and Flash gained wide popularity – mainly because they are easily available. And whereas development of Flash-based applications is quite a resource-consuming and expensive process, developing RIA with AJAX takes hardly more time then it would with an older-type, classical web-site. In most current projects Flash is only used when it is needed.

The very name – AJAX (Asynchronous JavaScript and XML) – reveals the essence of the technology. It allows the client engine and the server-based part of the web-application interact asynchronously. This means that your browser can request server at any point (say, when you hover your mouse over a link) and, vice versa, server can upload data to browser at any time, without waiting for a new page to be requested. How does it actually work?

One of the most popular uses that AJAX has found is in the web-based drag & drop technology. You must have already seen the virtual desktop services – such as found at www.netvibes.com and www.pageflakes.com. Their users can arrange widgets (useful data from other servers) on the screen and adjust their size just like we usually do it in Microsoft Windows. These features are now increasingly found in business-applications. For example, at www.atlas.cz users can customize the starting page with as much ease as any virtual desktop.

The possibility to customize pages with the help of ready-made design templates reduced the dependence of CMS (Content Management Systems) users on site developers. Using the mouse a CMS administrator can arrange various data modules, specify their size, color and other attributes at a page. Then s/he can save the current configuration which will later be displayed to site users. Yet advantages provided by Drag&Drop technology to CMS administrators are even greater when it comes to site content management. In latest CMSs all the administrator has to do to change position of any document in the structure (or of an entry in the list) is to drag and drop it at the desirable point. It is exactly the way files are managed in Microsoft Window Explorer.

As we’ve already mentioned, with RIA there’s no need to upload all the user data at once. Parts of it can be uploaded later, when they are actually requested for. For example, when administrator switches to the CMS’s site structure management interface, only the basic level of the hierarchy tree is loaded. If later user wants to explore any of the tree’s “branches”, the additional data will be uploaded instantly. This feature is even more important in managing various lists. The application returns to the interface only those entries that user specifically requested. Moreover, even data input procedures acquire new features. Modern web-applications increasingly offer input option which acquired wide popularity thanks to Google Suggest service. As soon as you start to type something in the required field, a dropdown list appears with suggestions based on the already typed in elements. Those who at least once had to, say, choose a producer from a seemingly endless dropdown list in the SELECT field will fully appreciate the convenience of this feature.

The fact that there’s no need to reload the page every time its user performs an operation changes the very perception of a web-interface. You can type in data in several forms placed on one and the same page but, say, on different tabs. Then all the data can be saved simultaneously. And, importantly, in case due to some reason (a lost connection, an internal error etc) the data is not saved, the interface will report it and let you try again. And we all know only too well that poor security was one of the basic flaws with older-type web interfaces.

It is obvious that apart from everything else IRA-based sites can report the status of processes and their results. Today it is only perceived as natural when any element involved in some system operations displays their status on a special bar. Let’s say, for example, that you requested a list of specified items to be displayed by an e-catalogue. In that case you have the right to know what the system is up to from the moment of query to the moment the list is displayed. If due to some reason the server is unable to return the requested data, you should receive the corresponding message.

With RIA the functionality and security of CMSs reach a totally new level, which earlier was available only with desktop applications. Yet we should not forget that RIA-based interfaces are capable of interacting not only with their own server software, but with third-party applications as well. This fact lets us hope that present-day CMSs will gradually evolve towards ECM (Enterprise Content Management), thus bridging the gap between corporate sites and corporate network information resources.

Posted by MixedSoup | No Comments »

Any business transactions who want nothing more than security, speed and accuracy of application use SOAP for information transportation between applications. Using HTTP, developers are able to use the internet and more specifically, the browsers to ensure that the application and information transfer will never require more than a stable internet connection. Based on current technologies today, SOAP web services is stronger than ever because of the advantages it ensures.

The development of Ajax development techniques made it even better for SOAP web based services. SOAP uses XML for data transfer which is a very smart choice. As a universal data mark-up XML could practically be integrated to any browser with the full security you can expect from any mark-up protocol.

Because XML is used in SOAP and Ajax it is naturally possible for developers to build SOAP web based services using the world’s most popular web and application development techniques today. You only need to inject JavaScript to the application and you end up with a good looking SOAP web services application fully activated with the support of Ajax.

We all know though that the actual development of an Ajax based SOAP webs services is not as easy as it looks. Ajax in itself is a very complicated web development technique and SOAP will even make it harder. An application for a business setting needs a very secured and tight coding and Ajax may not be able to live up to the expectations if they are not done well.

Basically, SOAP that will be activated with the use of Ajax needs four functions: WS.Call, SOAP.Envelope and XMLHttpRequest. XMLHttpRequest is of course the most important part of any Ajax based application as it is used to bridge the information and application to the application server which, in turn, activates the web service everyone is looking for.

SOAP.Envelope contains everything that you need in the application. The header, body and the element of SOAP is contained in the envelope. The envelope prevents the original application to be sloppy or prevents the application from being used in other functions outside the envelope.

XMLHttpRequest and SOAP.Envelope will only be activated with the help of another function – WS.Call. This function initiates the communication between the SOAP.Envelope and XMLHttpRequest.

All of these functions are enveloped in a WS.JS function which is a JavaScript function along with XML as a mark-up tool.

The usually setting for SOAP web services activated by Ajax is through Mozilla and Firefox type browsers. Unfortunately, the problem in Ajax is still very applicable to SOAP web services. XML functionality cannot easily happen in all browsers. Developers might have to develop two different XML forms just to ensure XML could be read in Mozilla, Internet Explorer and other browsers.

That is basically the challenge for any Ajax based applications especially for SOAP. Although there is no easy answer to build XML for browser incompatibilities, Ajax ensures good interactivity for users. Because it uses XML as its mark-up language, Ajax is naturally the next big thing for SOAP. A little tweak on the coding especially with JavaScript ensures that Ajax will work just as expected.

Posted by MixedSoup | No Comments »

When we talk about Ajax, we often encounter XMLHttpRequest, Flash, Java, iframe and frame functions. Without them, Ajax will practically be nothing. They provide the function and process data. But there is actually a trick on how to build an Ajax based program without using these functions. You don’t even need to fool the system and the trick is relatively simple. Unfortunately, there are no libraries or Ajax based frameworks that provide these functions so you may have to build it yourself.

An Ajax based program without these important functions will have three important factors. In every webpage, there is always the data, the image file and program that connects and processes them with the server or in the webpage itself if you’re building an online application. In a regular Ajax based program the data is on XML, pictures and other mediums are located iframe, frame, flash or Java and they are processed within the program by JavaScript and server to client communication is done using XMLHttpRequest. But since we won’t be using them while maintaining an Ajax based feel, we have to change them with other functions.

Instead of using frame we can use image so that it communicate with other functions and the server. To enable its communication with other programs and server, you have to wrap it with parameters and build it as an .src property. These are used to process for pictures, videos and other media types.

For data functions, we can use style sheet instead of XML or JSON. You could even make it simpler when you use CSS on that function. Think of it just like the RSS feed wherein it seamlessly accepts data and updates them on the server. When you cross .src and CSS together, you should be able to get a pretty decent webpage by now.

Of course to string them all together you still need some JavaScript functions to make it work. This ensures that you still have that JavaScript feel in your webpage and the server could effectively communicate with the client.

The most challenging about Ajax without the regular codes is working without the actual XMLHttpRequest. To active seamless communication without refreshing the whole webpage, we go back to the image file. When they are built with proper parameters and ended with .src, that would trigger specific communication with the server. Of course, .js which strings everything together will also communicate with the server. This 1-2 punch from the client is a good way to ensure that each program works well. JavaScript will communicate to the server everything that’s out of the webpage and they will be received by the image that was built with .src.

Unfortunately, there is a downside in this program is that it could only work when the cookies are enabled. It may just be a simple concern but wait till you launch this website. Almost everyone doesn’t want another website to access their computer. There are some changes that you could do but it’s just not worth it because you’ll spend so much time to properly configure them.

Posted by MixedSoup | No Comments »

Today we will take a look at a few AjaxControlToolkit tricks. If you have been working with ASP.NET long enough you know how important this function is to your Ajax based application. In fact, I have been looking online and most of the things I see related to the latest ASP.NET release are concerns regarding AjaxControlToolkit.

Without further ado – here they are:

Unlocking the language in CalendarExtender – CalendarExtender works only in English but that does not mean it will stay as it is. It is not that ASP.NET is biased for English-speaking users but since development is mainly in the English language, they might as well use it as their default.

But it could be unlocked and trick is surprisingly very easy. Look for the script called “EnableScriptGlobalization” and set it to “true”. That’s it! You just recompile the script and watch the calendar language change.

However, that solution is only good for changing the calendar. The header and the footer are still in English. Changing that is also relatively simple. The changes have to be done in the source code which is personally a little bit dangerous considering you have already tinkering with the underlying system.

Once you are there, look for this line: this._title.innerHTML = visibleDate.format(“MMMM, yyyy”);. The word you should look for is “format” and change it with “localeformat”. There are other date commands for header and footer and all you need to do is change it with “localeformat”.

Discarding Unnecessary Language DLL – this scenario happens when add a simple reference to AjaxControlToolkit.dll. That is a pretty simple action and should have no problem at all. However there is a problem which is really annoying. Along with the AjaxControlToolkit.dll, language directories get automatically piled up in the bin directory.

Even when you manually remove the directories, the subfolders go back once they are recompiled. Although that does not have any direct influence in the performance of the application, hundred of subfolders is very annoying.

The answer to this problem is to simple build another folder. Go to the Bin directory of your application and move the AjaxControlToolkit.dll along with its PDB to another folder. Just reference the folder using in your directory. There is a great chance the pesky subfolders will be removed since they do not have any references at all. But even if they will still exist, at least they are now located in a different folder.

Let the UpdatePanel do Force Full Page Postback – some will find this annoying but Force Full Page Postback can actually be useful in some situations. In a default situation, UpdatePanel can easily update some parts of the webpage.

Changing this format is very easy. The trick actually lies in the RegisterPostBackControl. By default, there is no additional information after this command or usually it should be controlled so that only parts of the webpage will be updated. But when you add (btnSearch); to the script, you will eventually have a Force Full Page Postback. All it needs is a simple change in one line and the function you need is right before your eyes.

Posted by MixedSoup | No Comments »

Communication from the server to the client sometimes is broken up that absolutely nothing is loaded to the webpage. It is a very easy concept most of the time since you will just load your XMLHttpRequest properly. However, the problem usually occurs when as simple as XML and HTTP cannot even recognize the request from XMLHttpRequest.

One of the tricks to ensure the program will properly load is to wrap the whole function in an AJAX loader. There are a lot of codes and samples out there but for today’s blog, we will take a look at a very popular script developed by Eddie Traversa.

What makes this loader remarkable is its simplicity anyone who has experience in Ajax and JavaScript will recognize how to customize the code immediately and complete the loader. This has been specifically built for XML and HTTP because it can easily handle these types of files. When your website transmits data asynchronously, XMLHttpRequest handles that stream of information but with the loader, you can make this work out even more.

There are just three steps to complete this function. Remember they can be customized according to your design specifications.

First is to load this code to your webpage’s header:

<HEAD>
<style type=”text/css”>
<!–
#contentLYR {
position:absolute;
width:200px;
height:115px;
z-index:1;
left: 200px;
top: 200px;
}
–>
</style>
<script type=”text/javascript”>
<!—Begin
function ajaxLoader(url,id) {
if (document.getElementById) {
var x = (window.ActiveXObject) ? new ActiveXObject(“Microsoft.XMLHTTP”) : new XMLHttpRequest();
}
if (x) {
x.onreadystatechange = function() {
if (x.readyState == 4 && x.status == 200) {
el = document.getElementById(id);
el.innerHTML = x.responseText;
}
}
x.open(“GET”, url, true);
x.send(null);
}
}
//–>
</script>
</HEAD>

Note that the header has already specified to whatever browser that you will have. Instead of additional headers you can even use this as your primary header since it is already complete in itself.

Next is to load this code in the event handler to trigger the server to load the file:

<BODY onload=”ajaxLoader(‘demo.xml’,'contentLYR’)”>

Of course, you can change the ‘demo.xml’ with any file that you have or even a little bit of an html content. Remember to place this in the BODY of your code or else nothing will work.

Lastly, place this code in the body of the html file:

<div id=”contentLYR”>
</div>

Your webpage will basically recognize that something exists somewhere and that they’ll have to load it as part of their webpage.

In summary, what you just did in to trigger the Ajax loader is inform the webpage that an asynchronous function is coming up. Then you load the xml file on the event handler so that it could communicate with the XMLHttpRequest when need. Lastly, a simple HTML code will fetch the file and load it in the webpage.

As you can see, the Ajax loader is very easy to use and customize. Credit is due to Eddie Traversa for providing us this code that could upgrade the performance of any Ajax based site.

AJAX Load XML File Script Authored by Eddie Traversa is featured on Dynamic Drive (http://www.dynamicdrive.com/)

Posted by MixedSoup | No Comments »