RichFaces, like most other rich/Ajax component frameworks designed for use with JavaServer Faces (JSF), was extensively revamped for compatibility with the significant changes in JSF 2. Joe Sam Shirah examines changed and new RichFaces 4.1 components that provide the same functionality he demonstrated in "An introduction to RichFaces" with version 3.1. He also updates the setup requirements for using RichFaces with JSF.

A key part of any Asynchronous JavaScript and XML (Ajax)-based web application is the communication layer between the client and the server. To implement this layer, you need to understand the various communication mechanisms that browsers provide, as well as each mechanism's pros and cons. In this article, learn to make the correct match between the specific communication needs of an application and the appropriate mechanism. Detailed examples show you how to create a communication layer that can meet these different client-server communication needs.

AJAX, rich Internet UIs, mashups, communities, and user-generated content often add more complexity than they're worth. They also divert design resources and prove (once again) that what's hyped is rarely what's most profitable.

Imagine that you are tasked to create a new application that will live in the Web 2.0 world. Some of your users are perfectly happy with HTML-based user interfaces while others expect every application they use to behave like Excel. Your business sponsor expects a productivity-enhancing user experience, but your CIO won't allow you to develop anything that a user needs to manually deploy. You know HTML won't cut it, but what else is out there? This article explores a series of Web 2.0 user interface technologies that enable you to build applications with better-than-browser user experiences. As a result, you can centrally deploy and manage them just like any other Java™ 2 Enterprise Edition (Java EE) application.

The jQuery UI package aims to create a well-defined and reliable set of user interface widgets that you can reuse within your own Web applications. The goal is to provide well-tested widgets that go beyond those available in HTML Input elements, and ease the work of all user interface developers.

Learn the tips, techniques, and pitfalls when developing Web 2.0 and Dojo applications. Wendi Nusbickel and Melissa Betancourt have worked on the Dojo application documented in this article for over a year. Having recently completed the development of a Web 2.0 Dojo prototype, they share the experience they gained when creating a custom Dojo application.

There are a lot of choices here. The X in Ajax is for XML, but XML is not a language, it is a toolkit for building languages. So your first decision is: do you use an existing language, or build your own? Several tradeoffs are involved. You have to ask if an existing language fits your needs or whether you can design something which is a better fit? Are there tools to process the language, or will you have to build them? If you communicate with others (and if not, why are you building a Web application in the first place?), how well known is the language? Will other applications readily be able to access and use your data?

Any programming problem can be solved in multiple right ways. This series looks at four approaches for creating an Asynchronous JavaScript + XML (Ajax) weather badge, a small reusable widget that's easily embedded on any Web page. This first article lays the foundation and examines the first approach—walking the DOM tree.

Aristotle, the Greek philosopher, once wrote "it is possible to fail in many ways..., while to succeed is possible only in one way." But then, Aristotle wasn't a computer programmer. While Aristotle's first conjecture certainly applies to programming—"it is possible to fail in many ways"—his second is nowhere near as certain.

This series of articles looks at four different approaches to the same problem. None of them is demonstrably wrong—each has its own set of strengths and weaknesses. The problem they each solve is not complex, and neither are the solutions. Even so, the approaches illustrate a wide range of trade-offs that can be embodied in even simple solutions.

In Part 2 of this series, Mark Pruett presents two more approaches to the Asynchronous JavaScript + XML (Ajax) weather badge. Both approaches use Extensible Stylesheet Language Transformation (XSLT) transformations—one on the server side and the other in the browser.

This series looks at four separate approaches for implementing the weather badge. In the first installment, the first approach used an Apache Web server rule to proxy the NWS XML data into the browser. Then, with JavaScript code, it extracted the required data from the DOM, reformatted it into HTML, and displayed it. This installment looks at the second and third approaches. These two approaches share one thing in common: they both use XSLT.

Ajax-style server calls don't necessarily require XMLHttp requests. This last installment of the series uses a public Web service, JavaScript Object Notation (JSON), and dynamic script tags in a final approach to the weather badge project. The same domain problem, explained in more detail in Part 1 of this series, is a security limitation that restricts XMLHttp requests to the same server that delivered the original Web page. In practice, many Ajax applications need data from realms outside that single server. This leads to design decisions that require access to Web server configurations (for example, to create Apache ProxyPass rules) or creation of special server scripts. As it turns out, you have another alternative. It circumvents the same domain problem, freeing the programmer from the requirements described above.