This makes me worry that none of the major JSF UI component libraries will > be using the built-in AJAX library because it doesn't have enough features. > Will JSF 2.1 complete the AJAX functional requirements of RichFaces and > IceFaces? > We will both advocate for vendors to use the built-in Ajax library and gather feedback as to where it is limited so that we can improve on it. Jim Driscoll has done a lot of work with the Ajax API and would likely be able to comment further. > > Can anyone comment on how the JSF 2.0 AJAX library compares to other major > Java web frameworks? Is it on-par, ahead of, or behind other web > frameworks? > It is certainly more conservative simply because we don't want to dump in the kitchen sink and then regret it after the fact. However, I know that the Ajax interaction itself is very clean, simple and should be very straightforward for most developers to understand. Again, Jim's blog is likely the best resource to get a feel for how this Ajax library is used for you to judge for yourself. > > ----- > > Another question I have is about hiding managed beans from views. If I > were to build a JSF 2.0 application that lets users customize the screens > with themes/skins, I would not want them to be able to access any and every > scoped bean in the system. To have this level of control I might need to > use a web framework that gives me more control such as Struts 2, because it > uses Freemarker and/or Velocity. > I'm really not sure I understand what you are getting at. Why does Freemarker or Velocity give you more control over bean access? > > Have you heard of anyone mixing JSF with Freemarker? > I talked to a developer at JBoss World that was interested in creating a module that would cater to this integration. But nothing concrete at this point. I can say that the whole idea of the VDL is to encourage other view languages to emerge. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan

The big concern is when the vendors make changes that make their components not interoperate with other components on a page - we'll be watching this closely, and seek to address it vigorously. But as a user and customer of those vendors, you can do so as well, by letting them know that component interoperability is important to you. Yes, the biggest toxin to the JSF ecosystem is the inability for components

And, as said in a different email on this thread: Other web frameworks' primary goal is to provide a complete Ajax solution. The goal of the JSF Ajax framework is to provide an easy to use set of basic functions which will be built upon by other members of the JSF ecosystem. This is markedly different than most other framework's goals.

I will give an example, below mentioned is the statuses I dont think this needs to be in the core spec, since the foundation of this is the listener system, every component lib can introduce statuses by using the listener system.

---------- Forwarded message ---------- From: *Ryan de Laplante* <ryan(a)ijws.com <mailto:ryan@ijws.com>> I read about the new RichFaces 4.0 being built for JSF 2.0 here: http://www.jroller.com/a4j/entry/richfaces_4_0_0_alpha1 They are still using AJAX4JSF instead of JSF 2.0's built-in AJAX library because: JSF 2 Ajax implementation still very limited and not contains our autoupdatable zones, limitations for autoupdate, statuses, table partial updates, server side processing options and so on. Queue in JSF not configurable at all.. Some of these points could be solved at application level by using some event's handling for example. But for some features - you will even not have a point to attach the functionality to. If the features that we provides with our ajax enchancements was implemented in JSF - we would not started reimplementing the weel for sure ;)