nextwebgen.com

Surveying open-source AJAX toolkits

Filed under: Web 2.0 News, Front Page, Articles, Toolkit — Chris Cornutt at 5:50 pm on Tuesday, August 1, 2006

In this new article from InfoWorld today, they look around the web and take stock of some of the more well-developed, strong Ajax toolkits around - six to be exact - and give an overview of them all.

If you want to add AJAX to the magic collection of buzzwords supported by your Web site (and who can resist the siren call of the latest buzzword?), then you have two major options: purchase a proprietary package or experiment with open source libraries.

InfoWorld has covered a number of excellent proprietary AJAX toolkits in the past, and now we’re turning our attention to some of their open source rivals. Are they worth exploring for enterprise use?

The six frameworks/toolkits they cover are:

Dojo
Zimbra Kabuki Ajax Toolkit
Google Web Toolkit
Open Rico and Prototype
Microsoft Atlas
Yahoo Ajax Library

They start with their reasoning behind their choices before even getting into the descriptions. They also have a reminder that these are their opinions on these toolkits, not to be taken as law - a toolkit is a personal choice.

For each of the toolkits, they talk about what it is, who makes it, how it works (all of the boring stuff) as well as their thoughts on its functionality, ease of development, and include screenshots for those more visually oriented. And, for the even more impatient in the bunch, you can skip right on down to the last page for six “cheat sheets” on the different toolkits, spotlighting the points made before.

Comments (0)

Rich Internet to Soon Replace Static Pages

Filed under: Web 2.0 News, Front Page, Articles, Web20 — Chris Cornutt at 8:43 am on Tuesday, August 1, 2006

According to the new article on the Tekrati.com site today, ZapThink is suggesting that rich internet applications based around the technologies of Ajax, Flash and Java will be replacing any and all static web sites/applications and portals.

Demand for Rich Internet Applications (RIAs) and more sophisticated user interaction is increasing dramatically, and enterprise spending on RIA applications will surpass $500 million by 2011, according to ZapThink. The analysts say enhancements to six types of business applications are helping drive RIA spending: high-transaction and event-driven Internet applications, next-generation portals, enhanced business intelligence solutions, application modernization, and Service composition or "mashup" solutions.

They talk about a report ZapThink has put out, showing that an end user experience with Ajax-enabled functionality, a nice interface, and good performance won out over a more traditional page structure. The RIA market is divided up into three submarkets looking at delivering components, environments, and extensions to help make the creation of these interfaces easier. They also mention four "primary means" of implementing these applications:

Adobe Flash virtual machine-based approaches
browser-based approaches that use JavaScript, XML, and other technologies (Ajax)
approaches that use Java applets or ActiveX controls
custom-developed Java or .NET clients

Comments (0)

Ajax and the Spring Framework with TIBCO General Interface

Filed under: Web 2.0 News, Front Page, Articles, Programming, Examples, TIBCO — Dietrich Kappe at 2:49 pm on Thursday, July 27, 2006

Brian Walsh has written an exceedingly well documented tutorial on combining Spring MVC, XStream and TIBCO GI. The focus is on using GI at the view layer while making only incremental changes to an existing Spring MVC application (the application from the Spring MVC step-by-step tutorial in this case, which you'll have to step through before you go on to the GI tutorial):

Application owners and developers alike predictably want to increase productivity and reduce time to market. This type of rapid implementation gives us several imperatives:

No wholesale replacement of our Spring investment.

Incremental change of existing server code as opposed to wholesale change to, for example, SOAP Web services

Continued support for non-Ajax clients

Re-use of existing code wherever we can. Develop the GI application along side the JSP layer.

Since GI generates the view at the client, Spring need no longer generate HTML at the server. Instead, we'll modify our Spring configurations such that Spring can also return raw data in form of XML that can be consumed as a service by the Ajax processes in GI.

The tutorial is generously illustrated with sequence diagrams, annotated configuration files and screen shots. It shows how to replace the HTML rendering logic of the existing application with an XStream-based logic that transforms the model into XML. (If you haven't looked at XStream yet, you really should. It's a clever library that allows you to serialize and deserialize objects to and from XML with a few lines of code.) All of the rendering is handled by GI in the client now, including degrading gracefully for non-AJAX clients.

The tutorial also serves as a lesson in how the development of web applications will change when WYSIWYG, component GUI interface tools become involved. The story board before-and-after shots of the UI in particular suggest some of the artifacts that might be produced in legacy web to AJAX migrations.

Comments (0)

Why XHR should support Cross Domain

Filed under: Web 2.0 News, Front Page, Articles — Dion Almaer at 9:39 am on Wednesday, July 26, 2006

Peter Nixey has written a piece on his frustrations with the lack of cross domain XHR in his current applications.

Clientside cross-domain data requests are an extremely useful tool. They can only currently be done (in Javascript) using the script-tag workaround to deliver data as JSON.

External JSON is extremely dangerous as it is arbitrary third-party code executed in the scope of the current web-page. It can be used to steal passwords or data present in the current scope. JSON is also a non-generalised data standard and requires new server-side libraries and code.

XML is already a data standard in wide use with API’s present in most programming languages. It’s inert, human-readable and highly compressible using gzip.

Any cross domain XHR must be server opt-in (rather than opt-out) or else we leave all non-enabled servers vulnerable to brute-force attacks.

Agreement can very simply be communicated by having the server send a header authorising cross-domain use of the data.

… any thoughts?

Comments (0)

Ajax File uploads to Amazon S3

Filed under: Web 2.0 News, Front Page, Articles, Ruby, Dojo — Dion Almaer at 10:05 am on Friday, July 21, 2006

Raphael Bauduin has written about his experience converting a Rails remote form into a dojo.io.bind call that enables him to upload a file:

File uploads are finally deployed! You can now specify in MyOwnDB that a detail of your entity is of the type “file”. This will let you attach a file to an entry, and subsequently replace or delete it. This required some changes in the application, more specifically in the way the forms are submitted back to the server.

For a file upload to work fine, you have to send it with the enctype attribute set to “multipart/form-data”. But that’s not all! You cannot just serialize the form in javascript like you can do with other input types because you cannot access the file from Javascript. The reason for this is security.

Luckily, the Dojo javascript toolkit has a workaround that works amazingly well, and is really easy to put in place. Dojo is facilitating all XMLHttprequest thanks to its dojo.io.bind method, which I discovered thanks to an article correctly title “Introduction to dojo.io.bind“. This article shows that dojo.io.bind can be used to send simple GET or POST request, but also to submit forms. At first, I thought it didn’t support file uploads (as stated in the document), but it does amazingly well. And, best of all, it is cross browser.

How does it work?

Dojo transparently creates an IFRAME, and submits the form through that IFRAME. That way, the browser itself is submitting the file. This has the side effect that you loose some functionality compared to XMLHttpRequests, like illustrated by the last remarks above.
I’m really happy with the result and the simplicity of the code. It allowed me to not touch any code outside of the form submission, and treat all form in the same way. When I started coding this, Dojo was the only solution I found, but Yahoo!’s YUI lib has gained the same functionality with its connection manager, taking the same approach of creating an IFRAME.

Comments (0)

Declarative Ajax

Filed under: Web 2.0 News, Front Page, JavaScript, Articles, Ajax — Dion Almaer at 8:26 am on Tuesday, July 18, 2006

Duncan Cragg thinks that The Right Way to do Ajax is Declaratively:

Don’t write your interactive Web application in custom Javascript! The Web’s Declarative nature needn’t be broken just because you want two-way dynamic data instead of one-way documents on your site.

Instead, write Declaratively to generic Javascripts, plugins and browser features such as Hijax, hInclude, XForms, SVG, XBL, etc.

Duncan goes into details of declarative talks from XTech this year and his thoughts on where we should be going.

Comments (0)

Ajax Portlet Communication with DWR

Filed under: Web 2.0 News, Front Page, Articles, Portal — Dion Almaer at 11:21 am on Friday, July 14, 2006

Sami Salkosuo has added fuel to the fire of the claims that "Ajax is perfect for portals and portlets, and we can finally do them right" with his piece DWR makes interportlet messaging with Ajax easy:

Many developers are looking to use Ajax technologies to improve the user experience of Web-based applications, but Ajax programming can be a tricky task. The open source Direct Web Remoting (DWR) library can make Ajax development easier for Java™ developers by automatically transforming Java classes into JavaScript classes. In this article, you'll learn how how to use DWR and JSR-168-compliant portlets to build an Ajax application quickly and easily.

The article has a lot of code to show by example, how this all works, most of it Java, with a touch of JSP:

<%@ page contentType="text/html"
import="java.util.*,javax.portlet.*,interportletmessagingusingajax.*" %>
<%@taglib uri="http://java.sun.com/portlet" prefix="portlet" %>
<portlet :defineObjects/>

function <portlet :namespace />sendOrderNr(orderNr)
{
document.getElementById("orderDetailsOrderNumber").innerHTML=orderNr;
document.getElementById("customerDetailsOrderNumber").innerHTML=orderNr;
MessagingBean.getOrderDetails(orderNr,<portlet :namespace />showOrderDetails);
MessagingBean.getCustomerDetails(orderNr,<portlet :namespace />showCustomerDetails);

return false;
}

function <portlet :namespace />showOrderDetails(orderDetails)
{
document.getElementById("orderDetails").innerHTML=orderDetails;
return false;
}

function <portlet :namespace />showCustomerDetails(customerDetails)
{
document.getElementById("customerDetails").innerHTML=customerDetails;
return false;
}
</script>

Comments (0)

Firefox Extensions and Ajax

Filed under: Web 2.0 News, Front Page, Articles — Dion Almaer at 11:34 am on Thursday, July 13, 2006

Dietrich Kappe has written about the hybrid world of browser extensions and Ajax.

As writting extensions gets easier (e.g. GreaseMonkey, or the extensions themselves) Ajax applications can potentially benefit from a tighter integration model with the browser.

Dietriche uses MyStickies as an example:

Another example of this curious Firefox Extension/AJAX hybrid caught my eye the other day: MyStickies. This extension will allow you to insert AJAX-DIV stickies onto any web page. The extension handles this insertion and also includes a Javascript library via a Javascript file from mystickies.com and another via chrome://mystickies/ for the behavior.

The sticky location is persisted to the mystickies site where you can also use a webapp to search, manage, etc., your stickies. It’s a direct manipulation bookmark that doesn’t reside just on your local computer.

Now I happen to think mystickies is pretty cool, especially if they implement some of the features on their roadmaps, like sticky sharing (how web2.0!). But what interests me here is the application architecture.