Ed Burns, spec lead for JSF, has made a set of screencasts for the recently released Java Blueprints components focusing on AJAX. These components leverage the Dojo Toolkit and make use of the JSF PhaseListener approach for serving up JavaScript files and handling AJAX requests on the JSF server.

A PhaseListener, for JSF, is much like a Servlet Filter acting on a JSF request, but it adds the benefit of full access to the JSF lifecycle, including components, events, and other JSF artifacts.

This is one of the areas where JSF offers quite a bit of power, because supporting AJAX is simply a matter of managing a request's lifecycle events instead of inserting extra components to manage different kinds of functionality, which also means that AJAX support for JSF components can work regardless of the JSF implementation.

You mean "this is one area where JSF *WILL SOMEDAY* offer quite a bit of power. If you are developing a product now, as we are, using AJAX with JSF is not pretty.

Then why bother???

Serve up some HTML and dish out Javascript..

Seriously though, all developers coming to JSF need to get their A's whopped with HTTP first.

Actually, you do not have to wait the SOMEDAY. The AJAX solutions for JSF already exist. The other will be announced soon. The JSF is AJAX-enabled technology. I cannot say the current one was designed for AJAX, just because the specification is written in pre-AJAX era. However, the architecture of JSF is very suitable for for working in the AJAX environment. I knew it for sure, because I am working as a Project Manager for one of AJAX framework for JSF - Exadel Visual Component Platform (the first version is released as a commercial product). Monitoring this specific area of our industry, I can say it will be a very crowd on this market during the nearest couple week.
If you still want to know about SOMEDAY and going to visit JavaOne this year, visit section TS-1161 there.

--
Sergey : jsfTutorials.net

You mean "this is one area where JSF *WILL SOMEDAY* offer quite a bit of power. If you are developing a product now, as we are, using AJAX with JSF is not pretty.

Actually I am working in this area for MyFaces (we also have moved to Dojo) and the two technologies fit together. There is no reason not to integrate Ajax into JSF, because DHTML and JSF is complementory and do not exclude each other.
There often is a situation where DHTML can reduce roundtripping a lot, for instance having something like a menu or client side tabbing.
Ajax also can increase the user experience a lot by avoidance of having roundtrips in tables.
And if no ajax solution is given you can revert to jsf mechanisms like server side event handling etc...
In the end the goal is that the users do not have to worry about ajax issues at all, they just should have a component tag and then be done with it, instead of having to think about integration issues.

The question do you use the whole range of the JSF benefits like components, lifecycle, listeners, validators, converters OR only the managed beans facility. If only the beans what is the difference in case of using, for example, Spring for the same DHTML <-> Server-side integration?

The question do you use the whole range of the JSF benefits like components, lifecycle, listeners, validators, converters OR only the managed beans facility. If only the beans what is the difference in case of using, for example, Spring for the same DHTML <-> Server-side integration?

I think we speak of several areas here

Well the main advantage of jsf+ajax is that you get the best of both worlds, you can use server side validation conversion etc, and you can use ajax to remote into the same facilities for client side validation for instance.
After all ajax is nothing new it just opens another path to the server which can be used during one single main page request as subrequest.
You can also use that stuff to enhance the user experience by making existing tags more dynamic.
Ideally I see the benefit of a good component framework over action oriented ones in this area, that you basically get the full experience in the long run without having to worry about all the server side, client side issue.

There is no reason why for instance
an entry field with a validator set cannot root into ajax at the same time for real time validation while the final one is done on the server.

Hooking events via ajax is trickier, because ajax per se does not allow callbacks, but it is doable.

And the good thing is all this can be done without having the users to think about those issues, for them it is just a validator set, or a tabbed pane set or whatever, no javascript nothing.

Sorry to break a lance here, but even though the entire dhtml programming model is broken due to browser incompatibilities, it still is a step forward (although a pretty old step forward) in the end I think the whole ajax dhtml craze is a fading trend and in a few years hopefulle the train will have moved onward to saner grounds (speaking of xul, xaml and other real rich client technologies with persistend and predictable behavior)

The question do you use the whole range of the JSF benefits like components, lifecycle, listeners, validators, converters OR only the managed beans facility.

This particular library does indeed leverage the components, lifecycle, and listeners capabilities of JSF. Components that are input fields (like the auto complete text field) also leverage converters and validators -- from the server perspective, they are just like non-AJAXified components and participate in a form submit in the usual way.

One of the benefits that is not necessarily obvious until you start programming with these components is that the encapsulation provided by the component can be very good at hiding complexity. The AJAX component (if you are using JSP) is just a custom tag with some attributes, just like any other JSF component tag. The fact that it renders a bunch of custom javascript, loads DOJO if it is not already loaded, and wires together event handlers for you is very beneficial.

For example, a typical use of the auto complete text field component might look like "<ui:autoComplete id="search" completionMethod="#{backingBean.options}"/>", where "options" is the name of a method on a managed bean that returns the set of options matching the prefix. Note that, besides encapsulating the initial rendering, it also encapsulates turning the returned list into XML (or whatever format the component wants to use -- that's an implementation detail the application developer should not have to care about).

You can do all of that with other technologies too, of course, but it is very easy to use JSF components to hide away all the complicated stuff.

If only the beans what is the difference in case of using, for example, Spring for the same DHTML <-> Server-side integration?

By the way, if you would like to use Spring's configuration files for defining your managed beans, this is not an either-or choice ... Spring comes with integration that uses a custom JSF VariableResolver to construct beans itself (if you have them defined), without the component having to do anything special with its binding expressions.

Craig

Even by putting dozen of auto complete text field component developer does not reach what she exactly needs. Sometimes, the AJAX activities is not only the behavior of particular component that do the same that already existing component, but does it in AJAX way. It might require the page-wide AJAX activity instead of component-wide one.

Even by putting dozen of auto complete text field component developer does not reach what she exactly needs. Sometimes, the AJAX activities is not only the behavior of particular component that do the same that already existing component, but does it in AJAX way. It might require the page-wide AJAX activity instead of component-wide one.

Sergeij I agree, there are some things where we run into exactly this problem in thomahawk as we speak. The two affected components currently are the state change notifer and the focus component.
Once you move away from componentization into binding the components there is a framework layer on top of the whole ajax component stack mandatory (for instance intra component dhtml event handling is such an issue, another one for instance in case of the focus component some infrastructure where component can register there focus target)

Even by putting dozen of auto complete text field component developer does not reach what she exactly needs. Sometimes, the AJAX activities is not only the behavior of particular component that do the same that already existing component, but does it in AJAX way. It might require the page-wide AJAX activity instead of component-wide one.

I agree, but I think "page-wide AJAX activity" is a bit too restrictive. What I'd *really* like to do is deal with a part of the page where that was appropriate.

One classic use case is validating a credit card number and expiration date (i.e. two or three components, depending on how you implemented the user interface). Doing an AJAX round trip for a single field ("on the user setup screen of your favorite portal site, is the username I want to use taken yet?") is pretty easy. A more general purpose solution would let you pass both the credit card number and expiration date fields in for validation, without having to submit the entire form.

Another obvious use case is a table that grabbed the data for the next "page" dynamically, without bothering to refresh the remainder of the current page. Same sort of thing if you expand a node in a tree control -- grab the data for the new nodes dynamically, instead of preloading everything at the beginning.

These kinds of thing are definitely possible with JSF, and there are some interesting experiments going on about how to implement them elegantly. Stay tuned for some nice options in this space.

Craig

I recently came across this project, Tobago. This includes lot of support for Ajax. Project is at http://myfaces.apache.org/tobago/index.html


- Rafiq
Ajax Today
http://www.ajaxtoday.com

I recently came across this project, Tobago. This includes lot of support for Ajax. Project is at http://myfaces.apache.org/tobago/index.html- RafiqAjax Todayhttp://www.ajaxtoday.com

Actually not only tobago: Here is some upcoming stuff for tomahawk (this is a private machine so please do not hammer the url)

fisheye

table suggest
timed notifier
input suggest
effects
general dojo integration
ajax form suggest
debug console

I am really jazzed about the current Ajax integration.

I can't wait until the integration gets tighter and becomes part of JSF.

On a side note, I created a very cool utility class (classes) that allow you to map an HQL query to the view with no Java code and it allows you to pass JSF EL expressions with no a Java code.

Warning... off topic side note.
See:
Easily pass JSF expressions as Hibernate Query Params (no code)
http://jroller.com/page/RickHigh?entry=integrating_hibernate_and_jsf_so

Here is a small sample
<code>
<bean name="deptsList" parent="dataProducer">
<property name="query">
<bean class="qcom.cas.commons.dao.dataproducer.QuerySpec">
<property name="query" value="from Department d where d.name like ? or d.name like ?" />
<property name="parameters">
<list>
<value>#{testBackingBean.filterName}</value>
<value>#{testBackingBean.filterName2}</value>
</list>
</property>
</bean>
</property>
</bean>
</code>

It can work with named queries and named parameters as well.

Rick Hightower (linked in),blog
JSF, Spring, and Hibernate training and consulting

I created the following screencast to show how great JSF is as a component framework. In just a few minutes I demostrate how a set of simple text field and be improved dramtically. The improvement include css, ajax, less error prone, and the web UI is generally more FUN.

The netbeans IDE help with auto complete and inline help.

A link to the video demo and more info is on my blog:

http://blogs.ebusiness-apps.com/godfrey/?p=15

I would love to get some comments; so do not be shy. Let me know how you feel about the video demo.

Cheers,
Godfrey