Pure Ajax creates the next generation legacy applications
Ajax has been in the limelight for over an year. While interest in the technology is high, there’s still large scale ignorance as regards Ajax solutions that can be implemented in Java applications.
In this interview we speak to Jonas Jacobi, who is an expert in Ajax and JSF. Jonas has some great suggestions on Ajax adoption and also points out common pitfalls that we might ignore in our excitement to adopt Ajax asap.
IndicThreads >> Hi Jonas! Congratulations on the release of your book “Pro JSF and Ajax” and thanks for agreeing to this interview. Could you introduce yourself?
Jonas Jacobi >> Thank you! It’s a pleasure to speak with you and to be able to reach out to your developer community.
Sure, for those of you who have not met me my name is Jonas Jacobi and I work as a J2EE Open Source Evangelist at Oracle. I recently published a book called “Pro JSF and Ajax: Building Rich Internet Component” which I co-authored with a very good friend, John Fallows (TXE Systems).
IndicThreads >> What do you think are the highlights of JSF and the reasons why you would recommend using JSF over competing frameworks / technologies?
Jonas Jacobi >> There are several reasons, of course, but there are two that sticks out as the main reasons why you would choose JSF over a competing frameworks. First reason is clearly the fact that JSF is an open standard and part of the newly released Java EE 5 specification. The second is related view technologies. As you are aware there is a tremendous buzz around Ajax and a lot of companies feel that they “just” have to have Ajax in their applications to be either competitive, or to provide adequate support for user interactivity.
“There is no migration path from a “pure” Ajax solution…”
What they don’t think about is that there is no migration path from a “pure” Ajax solution. The JSF model brings a clearly defined split between the UI and the behavior. This model allows the application developer to code against the behavioral aspects of the application with out being impacted by the view technology rendered to the client.
“JSF model brings a clearly defined split between the UI and the behavior…”
IndicThreads >> Is JSF a “UI Only” thing or does it have implications for the business logic and data access part of the application?
Jonas Jacobi >> From a first glance it might seem like that, which may also be emphasized by the fact that the JSF specification states “JavaServer Faces (JSF) is a user interface (UI) framework”. This statement has on occasion caused misunderstandings among developers believing that JSF is “UI Only”. But JSF is a “(UI) framework”, and as such it provides much more than just UI widgets.
“A key feature provided by JSF is the event model…”
We could probably spend an hour talking about the “extras” provided by JSF, but a key feature provided by JSF is the event model. This event model is borrowed from the JavaBeans spec and provides a strongly typed event model that allows the application to write server-side handlers (independent of HTTP) for client generated events. Very much like you do in Swing.
Another important feature is the Managed Bean facility. The Managed Beans facility offers a robust solution for creating and initializing managed beans e.g. a regular Java Class/POJO. When a Java Class/POJO has been registered in the JSF configuration file – faces-config.xml , it can be used in the JSF application. To access the managed bean developers will be using JSF’s Expression Language. For example to bind a JSF component to one of the properties of a managed bean (Java Class/POJO), developers can use the expression #{thebean.name} as a value argument to a JSF component.
IndicThreads >> How would JSF fit into the scheme of things for someone coming from a Struts or Spring-Hibernate background?
Jonas Jacobi >> I don’t know enough about Spring to make any assessments on its capabilities, but there are several solutions available on how to integrate JSF with Spring. Hibernate and JSF integrates well. Where JSF focuses on solving the user interface problem whereas Hibernate provides the backend services for that very same application.
“JSF focuses on solving the user interface problem…”
Struts on the other hand is a pure controller framework, whereas JSF is a UI component based framework with controller functionality. Although JSF and Struts to some degree are similar, there are areas where concepts are very different. This might affect some JSP/Struts developers, since they will have to learn, or accept, these new concepts provided by JSF.
“JSF and Struts to some degree are similar,
there are areas where concepts are very different…”
IndicThreads >> As a JSF application relies on UI components, do you recommend reusing existing open source components as far as possible or is creating new components for every application ok?
Jonas Jacobi >> I would recommend re-using existing components (open source or commercial), and only if needed create new JSF components. The benefit of a standard component model like JSF, is that you can mix and match open source, commercial, and your own home grown components with out problems (if you comply with the JSF spec.)
“You can mix and match open source, commercial, and your own home grown components…”
IndicThreads >> What is Oracle’s involvement in JSF? How is JSF related to Oracle’s ADF?
Jonas Jacobi >> At Oracle we believe that JSF is the most promising user interface technology coming out of the Java community. Oracle is extensively involved in the evolution of JSF, and is actively participating in the JSF JSRs and different open source initiatives. For example, we have been involved in the design of JSF since it was first drafted and we will continue to participate and provide our support for the JSF JSR (through Adam Winer, Oracle). We are also leading the JSF Design-time Meta data JSR (JSR 276).
“At Oracle we believe that JSF is the most promising user interface technology
coming out of the Java community…”
To assist and ensure JSF success and accelerate its adoption, Oracle decided to donate the Oracle ADF Faces component library to Apache Software Foundation (MyFaces). We hope that this open source contribution will spark additional interest and that more vendors are going to join the MyFaces project and strengthen the JSF community. For Oracle the ADF Faces contribution will be the foundation Oracle’s next generation of ADF Faces components.
Not only that, we (Oracle) are also leading the JSF tools project at Eclipse. This to ensure that developers, who choose to use Eclipse instead of JDeveloper, are as productive as possible building and deploying JSF-based user interfaces.
IndicThreads >> Your book talks of JSF with Ajax. However JSF has been around for a few years while Ajax was coined only recently. So is Ajaxed JSF a newer adaptation of JSF?
Jonas Jacobi >> Well, Ajax is a technique leveraging several “seasoned” technologies such as JavaScript, CSS, DOM, and XMLHttp. Most of these technologies have been around for several years, even before JSF. However, the term Ajax was coined February 18, 2005 by Jesse James Garrett.
“JSF is a perfect candidate for adopting new “techniques” such as Ajax…”
Ajaxed JSF ? With Ajax the software industry got a common “brand” for a set of technologies, which caused the spread of this technique like a wildfire. JSF on the other hand was designed to be UI technology agnostic. Making it a perfect candidate for adopting new “techniques” such as Ajax. At Oracle we have been using the Ajax technique for several years now and the ADF Faces components are all leveraging this technique out of the box. Before the term Ajax existed we called the technique Partial Page Rendering (PPR).
“Before Ajax we called the technique Partial Page Rendering (PPR)…”
IndicThreads >> Why do you think JSF and Ajax go well together?
Jonas Jacobi >> There are two (actually more than two, but we’ll keep it simple) types of developers – one that loves challenges and new technologies and techniques (the core developer), and one that cares about the actual application not necessary the technology behind it (the application developer). The core developer can use JSF to develop extremely rich user interface components using view technologies such as Ajax and XUL. These re-usable JSF components can then be used by the application developer without the need to know the intricate details of how Ajax works, AND at anytime the core developer can update the actual component without impacting the application developer.
IndicThreads >> Considering the immense hype around Ajax, most developers want to dive into Ajax irrespective of its need or consequences. Do you have any tips and warnings for such Ajax aspirants?
Jonas Jacobi >> As I mentioned earlier – developers that have been around block for awhile will almost certainly recognize a “pure” Ajax application as the next generation legacy application – sort of Cobol ++.
“A “pure” Ajax application is the next generation legacy application…”
Questions you should ask yourself are:
1) “Can I migrate my Ajax application to next generation web technologies?”
2) “Do I care if I cannot migrate?”
If the answer to the first question is NO and the answer to the second question is YES, then you should invest time in JSF. With JSF you can future proof your application, and at anytime replace the cool “Ajax” renderers with new renderers without impacting the actual application.
“JSF can future proof your application…”
This is also something John Fallows (my co-author) and I discuss and show in our book Pro JSF and Ajax: Building Rich Internet Components.
IndicThreads >> What’s the level of tools support for JSF + Ajax development? Any particular tools you would recommend the developer to have in his/her bag before they get down to developing real world JSF and Ajax applications?
Jonas Jacobi >> There are several good tools for Ajax in the works, but so far developers are still directed to use plug-ins to browsers such as the Venkman debugger from the Mozilla Foundation. When it comes to Ajax itself I would recommend that
developers look at already existing Ajax toolkits before creating their own, such as the Dojo Toolkit and Backbase.
For JSF there are several tools available such as JDeveloper 10.1.3, Eclipse JSF Tools project, Exadel Studio, and Sun Studio Creator.
IndicThreads >> Thanks Jonas. Any blog URL / email id you would like to share?
Jonas Jacobi >> There are several places that I would like to recommend:
My blog: http://www.orablogs.com/jjacobi
Apache MyFaces website: http://myfaces.apache.org
Oracle JDeveloper: http://otn.oracle.com/jdev
Eclipse JSF Tools Project: http://www.eclipse.org/webtools/jsf/index.html
Related:
>> Expect JDeveloper to grow at an unexpected pace
>> JDeveloper is the most comprehensive Java IDE available
>> Oracle Application Server is the fastest
>> Oracle donates Application Development Framework (ADF) Faces
>> Zimbra requests Apache Kabuki Ajax Toolkit withdrawal
>> Seven Ajax Frameworks / Toolkits to watch out for
>> Ajax technologies aren’t particularly new or sexy
Personally I think the Dojo toolkit is the closest we get to a JavaScript SDK. John and I used Dojo in our book long before it took off as a ‘defacto’ standard for Ajax development. It has since then improved tremendously and the founders have done a great job supporting its community. I don’t have any experince with JMaki, so I’m not able to make any statements that would be any value to you.
– Jonas
What are your thoughts on Dojo and JMaki. Do they work well with JSF?
Finally someone has spoken about how Ajax can go very wrong in the near future if we do not plan things well today.
Is JSF the only relatively secure path into Ajax?
Groovy won’t fully support annotations before 1.x or 2.0. And this @Property annotation was verbose and somewhat foreign to the rest of the language. So instead of it, we prefer a less verbose and simpler convention for defining properties (private fields with getter and setter), rather than a half-backed pseudo hard-coded annotation. This annotation was first introduced when the idea of AST (Abstract Syntax Tree) macros emerged, but which hasn’t been implemented so far, if ever.