I’ve completed the second component to my prototype-based AJAX widgets library: AJAX Rating Stars. This component features form-field binding, javascript callback support, and sending values via AJAX requests.
To download this widget, and for complete API documentation, please visit my blog.
Add comment August 28th, 2006
Recently, a co-worker of mine introduced me to the new Eclipse-based “Web IDE” Aptana. While it’s definitely still in beta (I’ve noticed many interface quirks), this open source project is quite possibly the best JavaScript IDE that I have used yet. Take a look at these cool features:
Code completion for JavaScript (Uses/parses phpDocumentor-style comments), HTML and CSS. It even includes DOM compatibility notes and cross-browser quirkiness checking.
Outliner that gives a snapshot view of your JavaScript, HTML, and CSS code structure
Error and warning notification for your code
Built-in simple HTTP server enables easy on-the-fly code checking
Built-in support for popular AJAX libraries, such as Prototype and Scriptaculous, speeds up environment set up
In all, the feature set is very impressive. The fact that it’s Eclipse based, and is available as a plugin as well as a stand-alone app, makes it even more attractive (I say this as I’m looking at my windows start menu — filled with 7 different editors for various technologies). As I said, it does have some random strange behavior like unexpected keyboard executions and some weirdness with autocompletion, but it is still in beta. I look forward to seeing a major release of this.
2 comments August 28th, 2006
I’ve created some ajax-enabled help balloons / tooltips, and posted them on my blog.
These balloons are based on the prototype.js javascript framework and use the Scriptaculous RIA Effects Library. They feature attractive PNG images for smooth transparencies and drop shadows, a very easy API and the ability to populate the balloon content via JavaScript, XML or HTML (via XmlHttpRequest).
Visit my blog @ BeauScott.com for more information.
Add comment August 26th, 2006
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:
<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.
1 comment February 19th, 2006
Over the last year or so, progress in developing Rich Internet Applications (RIAs) has been at a dizzying pace. It seems as though there are 2 new AJAX/JavaScript frameworks coming out every day. Products like Macromedia Flex and Laszlo have been introduced and improved quickly. These advances are both exciting and somewhat confusing. It is easy to see how such technologies can aid us in our projects, but how do we evaluate them? Which route is the best?
At first glance, it may seem odd to compare Flex and AJAX. After all, Flex is a commercial product sold by Macromedia, and AJAX is not even a cohesive package, but is rather a collection of technologies. However, it is likely that you’ll find yourself comparing them to each other, as they accomplish roughly the same goal. In fact, the server-side code you’ll write will likely be quite similar regardless of which route you go - I’ve had demos setup that used the exact same business logic for both Flex and AJAX.
With that in mind, let’s compare these two technologies with regards to several factors. Bear in mind, these factors are not exhaustive, and there is no clear “winner” - the technology you choose will ultimately depend to a large degree on the project you are doing. However, this should help you better evaluate your needs.
1. Cost
At the current moment, AJAX appears to be a big winner in this category. With Flex 1.5, be prepared to shell out at least $15k, if not more. AJAX, being a collection of technologies, is free. With Flex 2.0 (to be released in early 2006), pricing becomes much less of an issue for Flex, even though it will be still fairly expensive -rumored to be in the sub-$1,000 per developer range.
Cost, however, can be deceiving. Flex has many advantages (discussed later) that, in my experience, save considerable development time. I don’t even dare to count the countless hours we frittered away on browser compatibility issues on AJAX projects - such issues are virtually non-existent with Flex. Given that developer time is rather expensive, it doesn’t take a lot of time savings to make up the cost of Flex. Granted, some of these issues are being minimized by the numerous AJAX frameworks coming out, but there are still few cohesive tools for creating AJAX apps.
The role cost plays in your decision will depend on how large your project is. A smaller project with small overall budget will probably favor AJAX, whereas a larger one may favor Flex.
2. Tools / Community / Documentation
Development tools for Flex have been very powerful, easy to use, and somewhat resource intensive. The current Alpha release plugin for Eclipse kills my machine (Athlon 64 3400+, 2 GB of RAM), but hopefully that will be resolved. I have yet to see any tools that aid much in the development of AJAX apps, but one would expect to see some soon.
The community surrounding AJAX is quite large, helpful, and very active. One can setup a simple AJAX app in under an hour, making it very easy to get involved with. On the other hand, the massive investment required by Flex has limited its community size, though the forums at Macromedia tend to be helpful.
Documentation for Flex is quite good, though to my knowledge, there is only one good book out about it - developing rich clients with macromedia flex, by Webster and McLeod. There is certainly more info out there about AJAX, though it is less organized, so you’ll have to work to find it. There are numerous books either out, or soon to be out, written on the topic. My personal favorite so far is AJAX in Action, from Manning.
3. Speed of Development
This factor is perhaps the most difficult one to judge, since it is prone to be largely subjective. I personally have found that Flex lends itself to much faster development, due to the excellent tools for it and the fact that you don’t spend time dealing with browser issues or tedious css/html issues. Many colleagues I’ve spoken with have found the same, though I suspect there are many who may have a different take on this issue.
Things like prototype.js, OpenRico, and others will probably help the AJAX framework out in this area, and I see the trend continuing. For now, however, I would argue that Flex development is much faster.
4. Compatibility with Current Platforms
It is rare that we get to redesign an entire app in one project. Much of what we do in web development is maintaining, enhancing, and slowly replacing old web-based applications. Therefore, it stands to reason that being able to selectively use a technology can be very positive. This is one area where I think AJAX really shines, as it is quite trivial to drop in an AJAX component here or there, without significantly altering the page. Flex can be used selectively like this, also, but it generally is much harder to pull off.
5. Production Quality
One of my favorite things about Flex is that its built-in styling makes it easy to create professional looking applications, even if you are graphically challenged like me. Flex applications generally feel smoother, in my experience, than AJAX applications do. You can create visually stunning AJAX apps, of course, but it takes much more work.
6. Conclusion
As you can see, both platforms are have their advantages and disadvantages. I’ll be using both of them for years to come, I’m sure, but as Flex 2 comes out I’ll probably be using more of it. As soon as Flex 2 becomes more stable, I’ll probably be conducting another test using it and some of the newer AJAX frameworks that have come out. It should be interesting to see the results.
I’m also anxious to hear what others have to say about it, especially within the context of your own projects.
2 comments February 13th, 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 
Add comment 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?
Add comment February 13th, 2006