JSF Central - Ted Goddard on ICEfaces 2 and HTML5
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Community Chat
 
Ted Goddard on ICEfaces 2 and HTML5
by Kito Mann
05 Jan 2011 06:00 EDT

In this podcast, JSFCentral editor-in-chief Kito D. Mann discusses ICEfaces 2 and HTML 5 with Ted Goddard. Ted is the Chief Software Architect at ICEsoft Technologies and is the technical lead for the JavaServer Faces Ajax framework, ICEfaces, and the Ajax Push framework, ICEpush. He currently participates in the Servlet and JavaServer Faces expert groups. This interview was recorded in September of 2010 at JavaOne in San Francisco, CA.


Podcast (MP3)
Welcome to the JSFCentral podcast for the week of November 22nd, 2010. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology.
Kito Hello. I am here at JavaOne 2010, the first JavaOne under the Oracle stewardship. I am here with Ted Goddard, who is the lead architect for ICEfaces. We have both been enjoying the fall weather in not-so-sunny San Francisco. Welcome, Ted.
Ted Thanks, good to be here with you. I have to say it’s a lot warmer here than it is in Calgary.
Kito That’s a very good point. I live in the New York City area and it’s actually warmer there than it is here. It’s nice and windy here, though.
Ted No snow.
Kito No snow at all. So how are you enjoying the conference?
Ted It’s good. I have to say I miss it being in the Moscone.
Kito Me to. I have still enjoyed seeing a lot of the same people and networking and stuff, and getting some clarity on the Java roadmap is good. I agree. I miss the Moscone days.
Ted I am really impressed with what they are doing with Java SE. They have a lot of interesting stuff going in there in version 7 and 8.
Kito Yeah, definitely.
Ted Enterprise Java is shaping up really well, also.
Kito I am glad to see a little more adoption for Java EE 6 and some talk about what might be in Java EE 7.
Ted We will have to see, but it’s looking good on the roadmap.
Kito Speaking of roadmaps, you guys are working on ICEfaces 2.0, which supports JSF 2?
Ted That’s right.
Kito For those who don’t know, why don’t you spend a couple of minutes telling us… first of all about yourself, and then about ICEfaces in general.
Ted A little bit about me: I am the senior architect of ICEfaces. I have been working on it since the very beginning. It’s always been our goal to make it easy for you to build Ajax applications. One of the interesting things about ICEfaces is that when we began, the terminology Ajax was just coming out, and we actually misunderstood that. We thought that Ajax, the A in Ajax meaning asynchronous, should mean what we now call Ajax Push or what some other people call Comet. So we actually built that in from the very beginning and we saw that as an essential quality. Of course even today it’s still very much a quality beyond your typical Ajax framework. For instance JSF 2.0 Ajax includes Ajax features -- being able to update the markup in the page without doing the full page refresh -- but it doesn’t include Push features. You still need ICEfaces for that.
Kito Right. So you said that you started out thinking that Ajax meant asynchronous and everything. I know you have always used the term Ajax Push -- did you ever find people that were confused and didn’t know that it was the same thing as Comet, or anything like that?
Ted No, we chose the term Ajax Push because we felt that it was clear without having to explain it, whereas Comet is not clear without an explanation. You can tell people that “Comet is a joke, because Ajax is a cleaner and Comet is a cleaner and Comet is like this next thing after Ajax,” and that doesn’t really help you to understand the technology. That just helps you to understand the character behind the history. We think Ajax Push is a great term because it is immediately self-evident to anybody. They understand that you are pushing updates from the server to the browser over Ajax. Originally in 2005 we didn’t actually call it Ajax Push, we called it Application Initiated Update. That was kind of a mouthful and it didn’t catch on.
Kito Alright, so ICEfaces has always been very Ajax oriented, whereas JSF initially was not. Now we have added some basic Ajax features to JSF 2, sort of the low level Ajax functionality.
Ted The f:ajax tag.
Kito Right the f:ajax tag, and the low level JavaScript API, and also the standardized message format in partial view rendering, and all those kinds of low level goodies which are good in JSF 2. You are currently working on ICEfaces 2, which leverages those features, right?
Ted That’s true. One of the key characteristics of ICEfaces has always been the idea of transparent Ajax. What we mean by that is as the application developer, you are not an Ajax developer, you are an application developer. So when you work on your pages, you don’t have to think about how Ajax itself functions -- that’s a job for the framework. That’s been in there since ICEfaces 1.0. It’s always been the case that you simply need to put your JSF components on the page and then the ICEfaces framework, through its rendering process, turns that into an Ajax application.

Now in ICEfaces 2 this is still a very important quality, and we think one of the most important qualities. It makes you very productive as an application developer. You don’t need to worry about IDs on the page and what regions should be updated when there is a certain event. You simply put components on the page. That makes you more productive in terms of being able to use visual design tools when those finally mature for JSF. We seem to be going through a bit of a rough spot in terms of visual design, but when the visual design tools are available, ICEfaces will take advantage of those tools very well. Furthermore, when you think about generating a JSF application from a database schema, that can be very simple for the generator because the generator just needs to generate a plain old JSF application. It doesn’t need to worry about the Ajax aspects as well. There are strengths to this all through the pipeline.

Kito So in some ways, not in terms of the Push feature but in terms of some of the Ajax functionality, it is kind of similar to something like GWT. Like you can write all this code and even though you are sort of writing JavaScript but you are writing Java, you don’t have to really think as much about the Ajax stuff.
Ted You are just thinking about your application design.
Kito Definitely a good thing. ICEfaces 1.8 is the current version now, right?
Ted Yep, 1.8.2.
Kito And you are doing ICEfaces 2. What’s different about ICEfaces 2 from a developer perspective?
Ted The main new thing about ICEfaces 2 is JSF 2.0. That’s the thing that developers will really benefit from. They are already receiving a lot of benefit in terms of using ICEfaces on JSF 1.2, but with JSF 2.0, developers can take advantage of all of those features. Where it begins of course is what you are describing about how JSF 2.0 standardizes the way that Ajax is implemented, and the low level plumbing of Ajax. How the event’s collected from the browser and sent to the server, processed on the server, and coded back in terms of an update or edit list for the DOM, and then applied into the DOM. ICEfaces uses all of that. Before, that code was part of ICEfaces. We implement that whole pipeline in ICEfaces 1.8. In ICEfaces 2.0 we can delegate that to the standard, so that makes ICEfaces simpler. I would say that we truly are implementing the parts that make ICEfaces unique in ICEfaces 2.0. In ICEfaces 1.8 there was a lot of stuff that we were implementing that was really common to other Ajax frameworks, whereas now this allows us to concentrate on the really interesting features of ICEfaces, which is the transparency, the components that we have, and the Push capability.
Kito Okay, just so those who aren’t really familiar with ICEfaces understand, we have the Ajax capabilities and the Push features. Just talk a little bit about the components that you have on top of it as well.
Ted Our components – we have gradually been building up our component library ever since ICEfaces 1.0. There is drag and drop, there are table components, there are components for displaying tables in nice ways, pagination, scrollable or not, tab components where you can add the tabs dynamically, Google maps, rich text editor, effects. There is a whole variety of components there. A fairly complete set in terms of what you would need to implement in an enterprise application.
Kito Okay, so basically with ICEfaces 2, you are using the low level plumbing in JSF 2. Does this change the ICEfaces developer experience at all, or is it just that now they can use JSF 2?
Ted That’s very similar. With all of the 1.8 components that we have brought forward, they are ported -- they are not just tag compatible. In a lot of ways we have taken code from the 1.8 components and brought it straight across, just with a few internal changes to support JSF 2.0. There are some APIs that we have changed. For instance, the Push APIs have changed a bit so the developers will have to respond to that. What we have done is we have split out the push capability of ICEfaces. In ICEfaces 1.8, Push is kind of integrated throughout the system. The way that it actually worked is when you would invoke a render on the server, you would create a synthetic request and response, and run a JSF lifecycle at that moment. The reason we did that is because that allows you to create the DOM updates at that moment and send them directly to the browser. That’s the most optimal way to do that. For instance if you had a mobile device, you would receive just a notification with the updates at that time.

The problem is if you have multiple browser windows open, it’s not possible to have more than one Push connection open at a time. So you have to simply notify those other browser windows and have them fetch their updates anyways. In ICEpush, we’ve gone to an architecture where it is based entirely on notification. In ICEpush there is really only notification so you notify the browser client that it has something of interest. That is marked by the Push ID. Based on the Push ID the client knows what it is that is of interest. For instance, it knows which browser window has page updates for it.

You can take the same notification technology and apply it to pretty much any other Java system. For instance there is an ICEpush integration for Grails, one for Spring MVC, one for Wicket, GWT, and others… plain JSP. We have prepared all of these other integrations for all of these other technologies, where you can use ICEpush for that. Being based on notification makes it easier to scale because there is not a lot of buffering that needs to take place on the server side. It is really only buffering a single bit to say that you have been notified, unlike a message based system like JMS or Corba or Comet.

It’s also more secure, because what happens when you add a new message mechanism into your application that wasn’t there before? If you are sending interesting data over this new path, potentially you may be sending the wrong data or data that you don’t want other people to see. That means that you have to secure this other path. Not only do you have to secure it, but it’s a very different type of path than you are used to implementing in web applications. In web applications you are used to going through HTTP request and response, and we have all sorts of technologies for securing that interaction. If it’s just a message going out into the internet in a web application, developers aren’t as experienced with securing that type of thing. With ICEfaces you simply get the notification to a Push ID. The Push ID is randomized so an outside attacker can’t really tell what’s going on in the system. When you receive that notification, you request whatever it is that is relevant to that notification through the normal web mechanisms that you have already secured and tested. The idea is that it is as compatible and simple as possible for standard web applications. It doesn’t add a new messaging style on top of the web.

Kito So basically, instead of pushing out the changes, you are requiring another conversation. You have to notify, and then the JavaScript on the client is going to have to go back…
Ted It will go back to the server. Now there are advantages and disadvantages to that. It was kind of interesting… I had a conversation with the senior architect of eBay and he was talking about how important it was in their system to do things as lazily as possible. For instance when I mentioned that in ICEfaces 1.8 we calculate the updates and buffer them, but what if the client doesn’t ask for those for a while? What if a lot of clients don’t ask for those updates a while? Then you have buffered all of these updates and it’s going to be consuming resources on the server.

Whereas if you notify the clients instead, the notification is extremely lightweight. It goes out very rapidly through the system, and then any slow clients don’t take up resources on the server. Because when they get notified, that’s when you run the JSF lifecycle, which is the heavy weight application, and you actually deliver those updates. Not only is it more lazy, it’s also more compatible. Rather than being in a synthetically created lifecycle -- as we had in 1.8, where we actually had to do a lot of work to integrate with things like Seam and Spring Webflow, because they also manipulate the JSF lifecycle -- now it’s a standard JSF lifecycle request coming from the client, going through precisely the same code path that it would as if the user had generated an event themselves. What it does is it turns Push to Notify and Refresh, which is just like a user event. It makes the whole thing vastly simpler from a JSF point of view.

Kito So how does that work in situations where you have sort of a shared view among several browser clients? Do you want every browser to go through the lifecycle again, or do you do some caching, or how does that work?
Ted It would be just as if several users were using the same JSF application. That would be a normal situation if five users were all using the same application at the same time. Their views may be very similar but they may be slightly different. They will be logged in as different users, the timestamps will be different and they may have different records open. Those minor differences are essential. We are interested at looking at techniques where more data can be shared. For instance, it’s always seems possible with JSF that perhaps the component trees really are very similar for a bunch of users… then couldn’t we generate them and share them? The JSF component tree is highly mutable. It’s allowed to be mutable, but maybe there are applications where it doesn’t need to be mutable. Certainly in a lot of our applications, I know that the component tree is not undergoing a lot of change – it’s simply being regenerated in the same way every time from Facelets.
Kito I think there has been some discussion from the MyFaces camp about some of the stuff. Is there a way to have fully stateless views if we need to, sort of the way that Facelets are stateless?
Ted Facelets are common to all of the users in the application. I think there is a certain class of applications where that’s suited, and absolutely that could be exploited with Push, because when you send out a notification to a group of users, they are all going to want to render, and those component trees may all be identical in that case. I think that would be an interesting optimization to share that. That’s a future JSF change.
Kito Right, of course. Does ICEfaces still do Direct-to-DOM?
Ted So that’s still there and that works the same way it did before, essentially.
Kito It was easier to integrate it with JSF 2.0 because we have the standardized Ajax lifecycle in the pipeline so we use a DOM response writer and a DOM partial view context.
Ted Right now you can download a beta 1 of ICEfaces 2.
Kito And this is September 24th. So you can download a beta now.
Ted And there will be a beta 2 in October. And we expect a final release in November. There won’t be a lot of new components in that release, but it will contain… as far as components, it will contain the tools for you to develop your own components. There are three tools I’d like to mention.

First of all, as part of standard JSF, developing composite Facelets components is now far easier than it was with Facelets 1.1. Facelets components are now actually first class JSF components. ICEfaces transparent Ajax makes developing composite components uniquely easy because you don’t need to worry about any of the IDs in order to specify the Ajax behavior; you simply need to put the components in. What you run into trouble with -- in developing a composite component that has Ajax capabilities -- is you would like to be able to say "when I click on something in this composite component, something else should be rendered.” But that something else is probably many layers up outside of your composite component somewhere else in your component tree and it’s difficult, or maybe even impossible to express the ID for that something else. Now of course ICEfaces automatically will render that other thing for you and update the page. You don’t need to worry about it at all. I actually see ICEfaces as perhaps the only effective way to develop Ajax composite components.

Kito I think that you certainly could still do it without ICEfaces, but you would have to – in the scenario you are describing – you would have to in your composite component take into account that there was an ID so you would have to say “refresh IDs” and pass in something.
Ted Isn’t that very strange from the page developer’s point of view?
Kito I am not saying its good or bad, I am just saying that it would be much more like the model where you have to specifically mention IDs to rerender.
Ted That’s true. And then the composite component itself needs to be aware of these IDs and the whole thing is built with many layers of these IDs being passed around.
Kito Right, so you definitely would have to think about it, not only when you call the composite component, but in the composite component itself, you would have to then get that ID and make sure that’s the one you update using the f:ajax tag or whatever else.
Ted We see that as a tedious, low level process that developers shouldn’t have to be faced with.
Kito Right.
Ted Now there are reasons to pursue these tedious low level processes. In some cases you want optimization. And ICEfaces allows you to specify the render targets for using the f:ajax tag. If you do use an f:ajax tag with ICEfaces and say “only render this certain subtree,” ICEfaces will only render that subtree and it will only calculate the DOM diff on that subtree. That is available to you as an optimization technique. It’s not required for functional reasons.
Kito What is the other tool that you wanted to mention?
Ted Oh yeah, in terms of building components. Now we have some APIs in ICEfaces 2 to make components easier to develop. One of those is an annotation generator, where you create a component metaclass and in that metaclass you say what the properties of the component are, what the documentation is on those properties, and the generator will automatically produce all the artifacts that the component needs. For instance, for the actual component class, there are some TLDs. For each IDE, you need various IDE type artifacts that go with the IDE to show documentation and allow the component to be registered within the pallet and all of that stuff, and will allow you to automatically generate all of that stuff just from that component metaclass. We decided on using Java annotations for this rather than XML, maybe partly because we have grown tired with fiddling with the XML configuration files. Who knows, maybe we will swing back the other way one day, but right now they seem to be tiring. Really, you have the Java compiler sitting right there -- why not make use of it to express other information? It doesn’t make sense to go off and add in XML processors when you have the Java compiler perfectly capable of interpreting that information. Moreover, the metaclass, when you build that component, really mirrors what you want in the end. You have properties on those components… well those properties are Java types and all of that, so they should be expressed in Java. That’s why we went with the annotation based.
Kito I guess from your perspective -- developing a generator -- you don’t have to do a mapping between whatever XML type is defined and an actual Java type. It’s already clear.
Ted Right. It’s built into the source code.
Kito That’s kind of nice.
Ted So that’s available. We are using that to develop the new ICEfaces 2 components, and developers can develop their own components with that.
Kito So are you going to document that with the product?
Ted That will be documented. We will want people to develop components with ICEfaces.
Kito That’s good. Talking to lots of components developers, having a tool to generate the artifacts seems to be a pretty common thing and I have noticed that it really just depends on whether the company has the time or resources to make it available to other people. For instance, RichFaces has the CDK, their component toolkit and they do have a nice guide for that. If I remember correctly their metadata is XML based. I know that PrimeFaces has their internal component generator and I think Trinidad has a component generator too. You can go download it but it’s not very well documented or anything. I am very happy to see that now there are a couple of choices where you actually have something that is documented that can actually generate cool JSF components.
Ted We have put a lot of thought into these generators so I am betting there are some distinct advantages other some other component vendors’ generators as well.
Kito Cool.
Ted Then the third facility is the Sprite tool that we are packaging along with the generator. Besides generating these artifacts for IDEs and the components and such, components typically have a lot of images associated with them. They have images for multiple states the component can be in, as well as various decorative features around the component. For instance a tab might have various images used for the border of the tab. A rich text editor will have a toolbar with little buttons in various states. If you package those images as single images and deploy them as resources on the server, that means to load that component you have to do many HTTP requests to fetch all the images that are associated with that component. It’s far better to build them up into a single image and display that in just the right way, and mask it out with CSS. It’s called Sprite technique. Yahoo has been using this for quite a while in their web pages, and we wanted to apply it automatically to the JSF components that you develop with ICEfaces.
Kito Cool. So that means that the components that you guys developed that are either rewrites or new ones for JSF 2 can probably be a little bit faster in terms of the initial load time and everything.
Ted And the main user perceived speed aspect of web applications is the latency of that initial page view. It’s really important. If you can cut that time down, that will make them perceive the application as being more responsive.
Kito Cool. I have a question for you. What are your thoughts on HTML 5 -- first in general, and then in terms of ICEfaces?
Ted I think it’s a tremendous activity. There really doesn’t seem to be anything bad about it actually. We are seeing good browser vendor support. Even Internet Explorer is jumping in on it too. You need that, you can’t have just Safari and Firefox supporting the new standard. If Internet Explorer doesn’t support it then it’s of no use at all -- you have to fork whatever you do. Even say with SVG, it looks like Internet Explorer 9 supports SVG and it’s the same vector graphics that are supported by the other browsers. Now I am very interested in developing ICEfaces components that -- besides producing HTML markup -- produce SVG, because you can apply the Direct-to-DOM technique to modify just parts of the SVG, and now you have this very Ajax Push interactive graphical display. I think this is going to be very interesting.

In addition to that, they have standardized new sorts of input types. Being able to enter in a phone number in a web page, that’s a perfect thing to have with a JSF component, and that will be part of HTML 5... as well as the audio and video elements. Those are long needed to reduce the amount of plugins that we have on the web. I think HTML 5 is tremendous.

Where some of it’s not going… well, was not going so well, was with WebSocket. You would think that WebSocket has a natural application to ICEfaces with the Ajax Push capability, improving the networking technology that’s underneath, but unfortunately the initial version of WebSocket was really a very weak protocol. They went too far towards simplicity and not towards other necessary aspects of modern protocols, to include metadata and framing and multiplexing. But now the process has moved into the IETF and they are taking into consideration… essentially you have to take into consideration at least what HTTP took into consideration. If you ignore the lessons of HTTP and come up with a new protocol, you are taking a step backwards. The good thing is that now within the IETF they are really taking HTTP into account, taking its lessons into account, and I think ultimately when WebSocket -- now it may take years, but ultimately when WebSocket is defined it will be a well-defined protocol and it will be very useful for Ajax Push.

Kito That will be great to see. I will be happy to see when more of these things get well defined. I have heard someone say this week that 2020 was the target date for HTML 5.
Ted I don’t think it’s going to take that long. I think maybe when it’s all finally done, maybe that’s the date, but when Internet Explorer 9 comes out and there is a large subset of features that are in common, we don’t need all of HTML 5 to be done at the same time, we just need some new cool stuff that’s common to all the browsers. Now of course the other thing that’s really important in HTML 5 is that they have standardized the HTML parser in the browsers, and the error response – I forget the Ajax terminology they use in HTML 5 – but if your HTML is slightly corrupted, all of the browsers will interpret that the same way.
Kito Nice, I didn’t realize that.
Ted Which really means that you can get the same behavior out of all the different browsers. That’s one of the biggest problems -- not so much that your application doesn’t work in the other browser, it just looks weird in the other browser. Hopefully that will be a lot more predictable with HTML 5.
Kito One of the things I’m wondering… is there a way that we can think about in the future - maybe JSF 3 or something – how we can integrate offline storage. That’s another feature in HTML 5 and we have this way of declaratively defining your view and all that kind of stuff. There may be some way that we can take advantage of offline storage in JSF applications as well.
Ted I guess with client side state saving, you can imagine offline storage can hold the view state. That would be fairly straightforward.
Kito That’s true.
Ted More and more if you use offline storage, you do require execution in the client to take advantage of that offline storage. Right now, ICEfaces is primarily a server-side framework, and perhaps that will be the way it will be used for a long time because the data is really on the server. A portion of the data can always be sent down to the client, but the bulk of the data -- and the interesting things that you can do with the bulk of the data -- will always be on the server. I think there is going to be an interesting tug of war between client and server when we have offline storage. Certainly with ICEfaces now, how can we use offline storage? What we could do is we could buffer operations that the user is doing. Maybe they lose their network connection -- they go into a train tunnel and they click on a button. It shouldn’t break at that point. It should be aware that “I’m offline, I can save what the user has done, at least save this current event and maybe prevent them from doing anything else until I go back online.” But it would be very robust under those circumstances. Current web applications are not very robust, without the ability to store something there. That would be the first step. Then in JSF 3 we are going to need better ways to describe the client side capabilities, and what the components do client side, to take advantage of offline storage.
Kito I can imagine some really cool scenario where you define a data table and you basically have some parameters like “sync”… sync if it was true. So essentially you have some ability to synchronize data on the client so that it sticks around for however long or something like that. I’m not an HTML 5 expert so I have no idea how difficult that would be.
Ted I think the actual storage part of that is not difficult. The difficulty there is in transferring the data. Often with the distributed computing problem, you find out that “hey, I could parallelize this really well... I could ship it.“ But then you realize “it’s going to take me longer to ship the data over there” than any benefit you are going to get from parallelizing it in this very network disconnected environment. When you parallelize something you need things to be close together with a really efficient connectivity between the different nodes in the system. That’s one thing we don’t have right now, but maybe in the future when offline storage becomes more used by JSF, then we will have higher bandwidth and more commonly available network connectivity. Of course the other side of that is, if connectivity is better, do you need offline storage? I think that it’s going to be a very interesting future for that whole area.
Kito Definitely. Are you seeing a lot of use of ICEfaces in mobile devices in general, like IPhones or Android phones or other sorts of devices?
Ted Yeah, we are very excited about the application of ICEfaces to mobile devices. We do have a few customers that are using it. I think that it’s not the common case. Most people are using it on the desktop, but we are always working to improve the way that ICEfaces works in the mobile environment. That’s one of our very important initiatives. I would say that right now with ICEfaces we are leading the requirements of what people have. I think it will be exciting as more and more people use ICEfaces on mobile devices.
Kito Right. So do you have any ideas about what you want to see in JSF 3 or 2.5, or whatever it is?
Ted Certainly performance will be becoming important as people build bigger and bigger JSF applications. I think there are ways to make JSF scale better and better. We have made great strides with partial state saving in JSF 2 and there are probably more things we can do of that type. Earlier we were discussing the shared component tree and things like that. Then there will be other optimization ideas that we haven’t thought of at this time. It’s hard to look forward to JSF 3.
Kito Yeah you are still mired in JSF 2 right now.
Ted Yeah we are just busy getting JSF 2 out there.
Kito The only thing I can really think of that jumps out, other than optimizations and maybe a lot of the loose ends I think are being cleaned up in 2.1 which is what should be out relatively soon... I’d like to see more ways to define client side operations. So if there is something you know you want to happen on the client, some way to declare “do this on the client now,” and things like that. That’s kind of what I’d like to see.
Ted Whether it’s JSF 3 or not, standardization on… not the user interfaces of components, but perhaps the application interfaces of components. For instance if we were to standardize the way that a date picker works -- what’s the date picker tag, or what’s the data model of a date picker? Maybe date picker is easy because you pick a date. On the other hand though, as soon as you pick a range of dates or you pick a set of dates, things like that. If we were to standardize on some data models and perhaps tag interfaces, then component menus could produce tags that are compatible with all of that, and developers could easily use different sets of components with common data models.
Kito Yeah I think that would be helpful. I think the most common one for me is the tree model.
Ted That should be standardized. The model for that component should be standardized.
Kito That’s definitely something to look forward to. I guess for anyone who doesn’t know ICEfaces, it is an open source project, right?
Ted Yep Mozilla public license.
Kito Did we mention that your company name is actually Icesoft, not ICEfaces?
Ted You can find us on ICEfaces.org or ICEsoft.com.
Kito In addition to the open source version, you also have an EE edition, right? What’s the difference between the two?
Ted For that, I want to step back just a little bit to when we were talking about WebSocket. We say “what difference does that make?” We could kind of simplify and improve some aspects of ICEpush, but it probably would still have to support Internet Explorer 6. From the surveys that we see, Internet Explorer 6 -- even though they had a funeral for it -- it doesn’t seem to actually be dead.
Kito Sorry to hear that.
Ted It’s really in there at a 25% enterprise deployment market share, so that’s a browser that you must support. Why am I going on about IE 6? It’s actually quite difficult to support Internet Explorer 6. It’s an old browser, it’s very difficult to automate the testing for it, and that is one of the things that we have moved into the enterprise edition. With the community edition of ICEfaces, you have more rapid releases, but we are not testing on Internet Explorer 6 for all of those releases. We are testing on modern browsers. That open source edition is really only qualified on things that are easy to test for, things that the community can easily test on. With the Enterprise edition, we work from the same code base but on certain cycles we test on the more difficult servers to work with, such as Websphere, and we test on the browsers that are more difficult to work with, such as Internet Explorer 6. When you get the enterprise version of ICEfaces those are the versions that you know will work on Internet Explorer 6 with the commercial application server that you have.

Fundamentally if you want to decide “Do I need the enterprise edition of ICEfaces?”… Yes, you do if you require deployment into an environment where, say, you require Internet Explorer 6 to work across all of the features, plus you require an application server that is one of the more difficult to work with enterprise application servers, rather than an open source server like Tomcat, that we can very easily and regularly test with. Now of course there are a bunch of other things you get with the enterprise edition, such as a whole suite of composite components that we have developed that you get the complete source code to -- to modify as you see fit -- as well as load testing and functional testing scripts. There are scripts based on JMeter for load testing and some Selenium scripts that you can use to learn how to test your application on ICEfaces. Then there are training and tutorials, plus the support. You get very friendly support from ICEsoft. We love the people who license our software so we are very happy to help you.

Kito Ted personally will come over and… I’m just kidding.
Ted In some cases that’s what happens.
Kito There is one thing I did forget to ask you. What do you see for the future with ICEfaces 2 in terms of interoperability with other component suites? That’s kind of an important area.
Ted Yeah. We are very interested in interoperability and we think that now with JSF 2.0, interoperability really has a chance and it’s going to succeed. As I mentioned with ICEfaces 1, we had implemented a lot of this Ajax plumbing ourselves. Say with RichFaces, they have implemented the Ajax plumbing themselves, but in a completely different way from ICEfaces, so those things were not compatible. Whereas with JSF 2.0 we now have common plumbing, and we both can use it in the same way. The RichFaces value add and the ICEfaces value add can both sit on top of that and ideally co-exist. I have done some simple tests with some of the RichFaces components and they seem to interoperate, and now we are in discussions with them to look at making that an actual property of both of our frameworks, that they are interoperable.
Kito That would be great. Because if we could pick a component from you guys, and there was some cool component from PrimeFaces we wanted to use, and maybe other parts of the application were already written in RichFaces we could have it work together and it would be great.
Ted I think that is what every application developer actually wants.
Kito Yeah definitely.
Ted And as long as that person buys the components from all three of the vendors then all of the sales people are happy too.
Kito Yes and they will be much more likely to ensure interoperability. Makes everyone happy. Alright, well that’s about all the questions I had. Anything else you wanted to add, Ted?
Ted No I think I could reiterate the main benefits of ICEfaces: of course the transparent Ajax property where you don’t have to worry about using the f:ajax tag or IDs but of course you can use that for optimization on top of JSF 2. As well there is the ICEpush capability built into ICEfaces which is a very simple API -- really only two lines of code are what you need to turn your application into a Push application. Much simpler than developing it from scratch using common APIs or something like that. I’d like to thank people for listening.
Kito Well it’s been good talking to you Ted. I am sure I will see you again at a conference soon. You are flying out tomorrow right?
Ted Yep that’s right.
Kito Enjoy your flight back and whatever parties tonight that we go to. Thanks.
Announcer That's it for this edition of the JSFCentral podcast. The music for this podcast was composed and performed by Kito Mann. Thank you for listening.


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.