JSF Central - Dive into JSF 2 with Ed Burns
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Community Chat
 
Dive into JSF 2 with Ed Burns
by Kito Mann
29 May 2009 23:30 EDT

In this podcast JSFCentral editor-in-chief Kito D. Mann interviews Ed Burns about JSF 2. This was recorded in April, 2009 at JSFDays in Vienna, Austria.


Podcast (MP3)
Welcome to the JSFCentral podcast #14 for the week of May 25th, 2009. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology.
KitoHello, my name is Kito Mann. I am here at JSFDays 2009 in beautiful Vienna, Austria.
Ed It is very nice outside today.
Kito Yes indeed. I am here with Ed Burns who is the spec lead for JSF 2.0, and you were also the spec lead for 1.0, right?
Ed Right, well 1.2.
Kito Right 1.2 and parts of 1.0. So Ed, before we begin can you tell us a little bit more about yourself? Just so you know though, our topic here is JSF 2.0. I should mention that.
Ed Yes, of course. I will be real brief. I have just been so blessed to be involved with JSF since its beginning because it is a technology that really fits with my personality, I think, in a sense of being really outgoing with the community. We have really been blessed with a great community with JSF. Your efforts with JSFCentral and JSF 1 have certainly helped. It has just been a really great ride with the JSF technology.
Kito Okay, so tell me a little bit about what you were doing before you were at Liferay.
Ed Before that I was using Liferay Portal and JSF—actually I have to tell you about Stan Silvert. It was back at Java One 2005, I had been using JSF for about a year and Stan Silvert had a talk—I don’t know if you remember this—It was called Building Killer Portlets with JSF.
Kito So your technical title is Senior Staff Engineer?
Ed Senior Staff Engineer, right.
Kito At Sun Microsystems. You have been working in JSF for a few years now, right? What were you doing before you got involved with JSF?
Ed Before I was involved with JSF I worked on the Java plug-in, which has recently been re-written to be very nice with Java SE 6.0, and that was a much needed re-write that happened. Before then, it was really this kind of thing that kept going from version to version, never fully maintained as well as it could be. It was under staffed, but I worked on that and was fortunate enough to become a Mozilla committer for the Netscape/Sun AOL alliance during its time.
KitoRight, the brief period of time.
EdThe brief period of existence. That is what I did before.
Kito Ok, cool. So our topic is JSF 2.0 which is definitely the first major update to JSF. Major is a big word here. Not to say that your existing applications will break, but that there are a lot of great new features.
Ed Yeah but if they do break, please let us know. They shouldn’t be breaking.
Kito Of course, we have got the whole normal Sun mantra of “don’t break existing things.”
Ed First do no harm.
Kito Let’s talk a little bit about the key enhancements to JSF 2.0.
Ed The sort of organization that we took from way early in the process was to have this top five feature goals. The first one was to make it easier to develop custom components. JSF 1.0 and 1.2 never really delivered on the promise of having true abstraction, where you had black box components that were truly re-usable and self-contained and easy to develop. It just didn’t have the true abstraction. There were some leaks in the abstraction model. We wanted to fix that with JSF 2.0. We also had to have Ajax support. Now it is a given that you have Ajax in your web applications. Although… I guess it’s not a given in all circumstances -- some internal applications refuse to have JavaScript for security reasons. But we had to add it. We also wanted to bring in Facelets as part of the core specification. We wanted to make it easier to deploy applications, reduce the configuration burden, drop the faces-config.xml in most cases, and we wanted to provide for better compatibility between JSF component libraries from different vendors. The problem there was, of course, because JSF 1.2 didn’t cover Ajax and it didn’t cover resource loading, it left a lot of things off the table that people had to provide their own extensions for. Extensions from vendor A would often invalidate the assumptions made by vendor B, which means you can’t use those two technologies together. We wanted to raise the bar for what is the common playing field, and have component libraries from different vendors have a better chance of collaborating together in the same application.
Kito Okay, so why don’t we start by just drilling down into these a little more. We talked about making components easier to write. Originally, if you wanted to write a JSF component in JSF 1.2 or 1.1, you had to write a Java class, and then you had to also optionally write a renderer -- but let’s say you didn’t. Let’s say you wrote a Java class for the component. You then had to write a JSP tag handler, you had to register the tag handler with a TLD file, then you had to register your component in faces-config, right? So it was kind of a lot of work.
Ed Yeah it was.
Kito Tell us about how JSF 2.0 simplifies that process.
Ed We wanted to look at all the artifacts – you just enumerated all the artifacts – and we wanted to reduce it to just one, a single artifact. We were able to do that. Now you can write a custom component by making a single XHTML page and placing it in the proper place in your web application directory structure, and it will appear to the user as if they are using a regular plain JSF component. The way that works is we took Facelets – Facelets kind of already had this capability to do compositing, of course -- and you could build components with Facelets in this way but they had some shortcomings as in they were not true JSF UI components. The user could treat them as a real component, and attach listeners to them, and have them emit events, and all of the other kinds of things -- validators, converters -- that you would want to do with a component, that wouldn’t work with the Facelets way of doing things. We took the Facelets code and we brought it into the spec. We were able to make modifications, and now we can have a system where the XHTML-based component has all these properties built in. This pattern happened again and again with our development of JSF 2.0, where we saw what we needed to do, and then we looked at what we already had that kind of did it, and we just found the most elegant and sensible way to bridge the gap between those two things.
Kito Right. That is one of the things that I like about this spec, that it really does follow the rule of not trying to invent a whole bunch of new things.
Ed Right, we clearly didn’t want to. JCP is not the place for innovation; it’s the standards body. That is one of the things that – we are claiming happiness and success with JSF 2.0, but I think the real measure of success is how well we did at taking the innovations that were made in the open-source and competitive marketplace community, and standardizing them and bringing them into the spec. I would like to hear what people think about that, because we certainly had all of the stakeholders who had done the innovations on the expert group, but I would like to see if the people who have been using, for example RichFaces, if they are satisfied with the Ajax solution that we now have in JSF 2.0.
Kito Right. So just to talk a little bit more about the whole composite component thing, we have got it down to one artifact but that doesn’t mean you can’t still write code if you need to, right?
Ed Of course, right. The nice thing is we have a set of rules, where if a page author puts a tag in their page and a component can’t be found for that tag, then we have a set of rules where we look first. Is there a Java class with this class name? And if not, is there an XHTML file with this filename? We have a set of steps that are followed on a convention basis. Each one looks: “can you resolve yourself to a component?” And there is even a step where the spec says “look for a script based resource with this name.” That gives the implementations such as Mojarra the ability to build the script based component out of Groovy. Sun’s Mojarra was the first one to have Groovy support. It is very well matured now to do your components, or any artifact really, in Groovy.
Kito Now we have got it to a point where you can start with a simple Facelets or composite component XHTML file. And then if you want you can add logic in either Java or a scripting language, and then if you still really need the full-fledged stuff – let’s say you need a separate renderer that is written in Java – you can still do that.
Ed Right.
Kito I think that is probably my favorite feature personally.
Ed We wanted to have agility. The dream was to have a system where it would be quick for prototyping and it would also be solid for maintainability. The technologies out there – for example, Rails is great for prototyping, but I have heard actual feedback from people who do consulting on Rails projects, that they are happy about it because it is so hard to maintain, that once a product gets delivered, it’s a revenue stream for them for maintaining. So with the JSF project we wanted to have it agile, where you could do script things in the beginning, and then you could gradually convert and migrate the projects artifacts over to more solid compile time and compile time type safety and all those other features that are nicer about Java.
Kito Right. So we talked about the XHTML file and bringing Facelets into JSF. For people who aren’t really familiar with Facelets – for the few people out there -- essentially it is a replacement for JSP in the simplest terms. So tell us about the view description language, or Facelets integration, in JSF 2.0.
Ed Well we did a survey of the expert group members about how they felt their users were leveraging Facelets, and the main question we asked was “are they using the Java API for Facelets or are they just using the markup, writing pages in XHTML and doing templating in XHTML and that sort of thing?” The vast majority felt their users were only interested in the markup side of it, so that gave us the necessary freedom to change the Java API as we needed to, to minimize its spec footprint. We really wanted to emphasize the markup based usages of Facelets. We felt that use cases for people who were actually extending the Facelets component handler or calling the Facelets context class directly was relatively small. We would rather not have to expose any of that. We took the minimum set of what we had to expose and put it in there so there is a new package, javax.view.facelets, that has all of those Java APIs that we need but they are different. Similar but different from what you would expect if you were looking for com.sun.facelets packages.
Kito Right. So in a JSF 2.0 application, by default you use Facelets for all the templating. You don’t have to add any libraries, it’s all fully integrated. Doesn’t mean that JSF 2.0 doesn’t work with JSP though, right?
Ed Right. JSF 2.0 will run JSP applications, but very few of the new features that you might want to migrate for are actually accessible for JSP users. What the strategy we envision is, people will take their existing JSF app that might use JSP, probably uses JSP, and then they run it in the JSF 2.0 runtime and then they make a page by page migration. Where you run into problems is if you have a JSP custom tag library for JSF that doesn’t have a Facelets version, then you do have to migrate that component library to do that as well. We expect that there will be some tools written to help ease that process.
Kito Okay. I think that is another great feature, the whole Facelets thing. Let’s see. What else was there?
Ed Ajax.
Kito That’s a good one. Okay so with Ajax the main thing was that JSF 1.2 really didn’t have any specific support for Ajax.
Ed Right, we would like to say that JSF was ready for Ajax before Ajax was…why it was popular. By leveraging the design principals of age old UI component libraries, going back to Motif and the Windows 32 API and all of those old school things where they focused on properties, methods, and events for each kind of component, we were able to be ready for Ajax when it came around. That is why the people who had built Ajax based libraries, such as RichFaces and Dynamic Faces and ICEfaces, felt that it was a really good fit between the two technologies. We were able to take the existing efforts that people had done, and put them in and standardize them.
Kito So when you say “take the existing efforts and standardize them,” what does that actually translate to in terms of specific artifacts or functionality?
Ed Well, all of the Ajax component libraries had some way of taking a JSF page, you download it once into your browser, and then the individual components in the page will be updated as the user interacts with the application via Ajax. If they mouse over, or type in an auto-suggest box, if they type a few characters in, then the user sees magically the suggestions appear based on what they have typed already, that would happen over Ajax. The way that was done with existing JSF libraries was you would have a custom component that would sometimes even just wrap an existing JSF component. Like if you put it in Dynamic Faces you would say “Ajax zone,” and then put your components inside of it, and then there were rules on the Ajax zone that would determine how the request would be sent to the server. So there was always a common feature where there had to be some piece of JavaScript that would be able to make XML HTTP requests, do it in a way that the view state was sent along with the XML HTTP request, and then have some syntax that the server would send back a partial update, which the JavaScript would then receive and use the JavaScript inner HTML feature to replace those things in the direct DOM. So all of the existing Ajax libraries had that capability, so we just had to figure out how to best standardize it. We worked very closely with the RichFaces people and the ICEfaces people and people from Oracle to get that goal. Roger Kitain, my colleague on the JSF spec, did all the Ajax work and he did a very good job.
KitoYeah and I think basically what we ended up with is the low level, an actual very simple, easy to use JavaScript API, right? And obviously the corresponding server side changes to do partial updates to the component tree.
Ed Right and we did come up with an XSD and XML schema for the partial response syntax, so that was really vital. If we are going to be open and we are going to be a standard we have to standardize that interoperability layer there. Because it is a standard, you can imagine people writing JSF extensions that have JavaScript in them that know how to interpret that partial response, and do other things with it.
Kito Also at the fundamental level in terms of using Ajax, if you are not using a really full blown component suite like RichFaces, the Ajax stuff is exposed via simple JSF tags, right?
Ed Yes, there is actually only one JSF Ajax tag in JSF 2.0.
Kito I guess there is only one tag.
Ed It is
and that’s it.
Kito Right,
Ed The design, which I think was arrived at with Roger and Andy Schwartz and Alexander Schmirnoff was that you could take the
tag and either wrap a bunch of components and then they get Ajaxified – which was the Dynamic Faces model. Or you can nest it inside the component and it would become Ajaxified – which was the RichFaces model. They unified the semantics of that and the nice thing about when you nest it inside, it is able to leverage some knowledge that the individual component has about “how am I best Ajaxified?” If you put it inside of a text field then it knows it is on the onChange JavaScript event. If you put it inside of a button, it knows that it Ajaxifies the onClick event. We leverage the inherent nature of the component itself, we leverage that to Ajaxify it. I think that is a really good measure of a design, where you extract the maximum meaning from things.

It is basically the DRY principal – Don’t Repeat Yourself. I have already said that this thing is a text field. Well, text fields, what do they do? You type values in them and the values change. What do buttons do? You click them. That information is encoded by the user when they say “I am putting a text field here.” Why have them put it twice? Convention over configuration.

Kito Right, yeah definitely. It’s funny because I knew there was only one tag but since it is so versatile, I was thinking there must be more than one. Conceptually it is similar to Ajax4jsf.
Ed Right. That is what I was saying; it is like a4j.
Kito Right, but for people who are probably used to typing a4j, I just wanted to point that out. So we have talked about the standardized Ajax or JavaScript layer for Ajax and everything, and obviously it allows you to Ajaxify existing simple JSF components. But one of the key benefits is that third party component suites can then use this Ajax layer themselves internally. This helps with the whole component interoperability.
Ed That’s the whole story.
Kito So there is one other element to the component interoperability, right? And that is the resource handling.
Ed Right, and also the ordering.
Kito That’s a good point.
Ed Because in our top five goals here… it is interesting, this is something I have been mentioning for years when I talk about -- because we have been doing JSF 2.0 for 20 months now so I am very glad that we are done. By fixing Ajax we had to introduce some things that did provide for better compatibility….
Kito Exactly.
Ed The thing you are talking about is the resource loading. In order to get Ajax working we first had to figure out how we were going to package the JavaScript files themselves, and send them down to the client, and standardize on the name of the file itself, and the functions that we are putting into the library, and that provides a big time interoperability boost. We fully expect that each – well, we wanted to make it possible for A4J or ICEfaces, if they wanted to override the act of providing the standard jsf.js file, that they could. If they need to override it, they just have to adhere to the specification, and they could be just fine. They can decorate it if they want, but they don’t have to. That would be funny, that that’s a compatibility problem, right. What I am saying to our vendors is “please refrain from decorating the jsf.js because if you do, you will likely break the other component libraries and that was the whole point.”
Kito True. But the main thing is the component libraries can load resources from JAR files and they can be versioned right?
Ed Right, versioned and localized. There was some debate here at the JSFOne conference about the best way to specify the path to a resource. Someone was saying that the current design that we have will end up with – the way we have locale at the front, rather than at the end, can result in lots of empty directories. So you know, yeah that can be, but we did make the resource handler pluggable, so if you want to fix that you can.
Kito Right. You were saying the other thing that helps is the ordering of extensions.
Ed Right, so we were able to do some work to make it possible for any faces-config to give itself a name and then you could say “do you want to be before or after any of the other well-known faces-config?” So if you have a portlet that is doing some decoration by providing some custom FacesContext or something, they need to say “I want to be at the bottom of the chain. I want to be so that if anyone does any decorating I am the one that gets decorated first.” That is something that was an important aspect of cross-component library compatibility.
Kito Right, right. Okay so I think the other thing we mentioned was reducing the configuration burden.
Ed Right our story there is annotations largely. We now have a system where you don’t need to have a faces-config. You can build a complete JSF application with navigation and everything, and not have a faces-config, because you have annotations for your managed beans or custom validators, custom convertors, whatever you need there, and your navigation can now be handled in the page with what’s called implicit navigation, where you would say “
” and it would submit the form and go to the register.xhtml page. So that was a good feature.
KitoYeah and it is one of those things that is going to have a pretty profound impact on using applications here.
Ed Right, so providing some guidance is very important. When we give these new features out into the world, people often ask “well, when is the right time to use navigation rules versus having your navigation hard coded into the page?” Again it comes back to flexibility and agility, because when you are prototyping it is handy just to put the rules right in the page. Then you boil it down and put in the faces-config rules and that gives you the ability to maintain it better. By putting your navigation all in one place, you can understand the application much better than if you have to go and look at a whole bunch of different XHTML files.
Kito Right, exactly. Alright, so I think we are about out of time, but I must commend you, Ed, on your outstanding work as a JSF spec lead. I think you have done a great job.
Ed Thanks and I give thanks to the group of course, and especially to Roger and Ryan and Jim, the JSF team at Sun.
Kito I encourage everybody to check out JSF 2.0. It’s a great new release.
Ed The Sun/Mojarra implementation is a product quality ready-to-go implementation for JSF 2.0.
Kito Alright Ed, anything else you want to add?
Ed No I think we covered pretty much everything Thanks for the opportunity to talk. I am looking forward to it.
Kito Maybe by the time you hear this, the spec will be complete or almost complete, but it has been kind of in tandem with the spec all along which has been great. Thank you very much, Ed. Enjoy the rest of the conference.
Ed Alright thanks.
Announcer That’s it for this edition of the JSFCentral podcast. The music for this podcast was composed and performed by Kito Mann.


RSS feed(all feeds)

The Editor's Desk
Podcasts
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2014 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.