One of the biggest complaints I have heard about JSF is how difficult it can be to use Ajax with. Indeed, it can be difficult to do so, and you often must go outside of the JSF way of doing things in order to get an Ajax component to work. There have been several good components that use Ajax (MyFaces has several) and some good Ajax implementations of the normal JSF components (ie, ICEfaces). However, if you plan on doing something other than exactly what the components do, you are out of luck.
With this problem in mind, I created a set of components to allow a little more flexibility. You can attach an Ajax listener to any input component, and listen for any type of event. Then you attach any number of Ajax Response listeners to that Ajax Call component to do the work after the response is returned. For example, let’s say you have a form where the user needs to put in a model number for a particular product, after which a text box will be filled in with the product name. Your code would look like this:
<t:inputText action=
“#{productBean.prodcutName}” value=
“#{productBean.productId}”>
<u:AjaxCall event=
“onchange”>
<u:AjaxResponse status=
“success” forId=
“productName” forAttribute=
“value” value=
“$returnValue” />
<u:AjaxResponse status=
“failure” function=
“onFailed($returnValue);” />
</uAjaxCall>
</t:inputText>
<t:inputText id=
“productName” forceId=
“true” value=
“#{productBean.productName}” />
<f:verbatim>
<script>
function onFailed(error){
alert(“There has been an error” + error);
}
</f:verbatim>
This solution seems a little more flexible than some of the other stuff out there (although, if you want an input suggest box, you should use the one from MyFaces) and follows the JSF model. It uses the prototype.js library for the Ajax calls. I will be providing the source and binaries via SourceForge shortly, thanks to my employer (rFocus, inc) allowing me to release the source. Anyone interested in helping further the development or just using it can contact me, or check back here for updates.
February 19th, 2006
There is a lot of repetitive code you’ll run into in your average JavaScript project. I frequently found myself making libraries for each project that had code for making HTTPRequest objects for each browser, shortenting document.getElementById() calls, and doing several other repetitive tasks.
I recently came across a very good library that does many of these tasks and does them quite well. You can download prototype.js here. There is some unofficial documentation for it, written by Sergio Pereira, which can be found here. I cannot count the number of hours this little script has saved me, hopefully you’ll find the same
February 13th, 2006
(This post is cross-posted on SpencerUresk.com)
Without a doubt, AJAX is one of the most popular new web technologies of 2005. Its rocketing popularity has led to numerous frameworks and projects to tie it in with existing frameworks. For example: ICEFaces (Java/JSF), MonoRail (.NET), and Ruby on Rails (Ruby). No doubt, tying AJAX components into an existing framework can save loads of time and cut down on the amount of code you have to write. What about coupling though?
I have taken the approach that AJAX is an entirely new layer, and have tried to keep its code separate from business logic. Why? By doing so, you can change any layer without messing up the other one (in theory!). Suppose your boss decides you need to move from a PHP solution to Java, or from .NET to Java - if you are using an AJAX framework that ties into .NET or PHP, you’ll be stuck rewriting a lot of presentation code that needn’t change.
Likewise, what if you have to move from AJAX to something like Macromedia Flex?
If your PHP, .NET, Java, Lisp, is spitting out generic XML, changing the presentation layer shouldn’t take a ton of work - indeed, I have switched presentation layers in exactly this manner, and did so with only minor changes to server-side code.
Or, perhaps you need to make your website more accessible, but you like the rich and interactive experience AJAX provides. If you are getting generic XML back from the server, you can just make a new presentation version that uses XSLT to create a simpler, more accessible website.
To me, AJAX presents an opportunity to have truly separate presentation and logic layers, but maybe I’m missing something. Am I?
February 13th, 2006