JSF Central - Brian Leathem reveals RichFaces 4.2 and discusses SeamFaces
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Community Chat
 
Brian Leathem reveals RichFaces 4.2 and discusses SeamFaces
by Kito Mann
31 May 2012 03:00 EDT

In this podcast, JSFCentral editor-in-chief Kito D. Mann talks with Brian Leathem about RichFaces and the Seam Faces Module.


Podcast (MP3)
Kito Hello and welcome. My name is Kito Mann. I am the editor in chief of JSFcentral.com. And today is-what's the date here? Oh yeah, February 15th, 2012. And today, I'm doing a Skype podcast interview with Brian Leathem who is a senior software engineer with JBoss by Red Hat, and he's a RichFaces core developer and also the module lead for Seam Faces. Hello, Brian.
Brian Hi, Kito. How are you doing?
KitoI'm doing well. How's the weather treating you? Where are you located, anyway?
Brian So, I'm in Vancouver, Canada, on the West Coast. And we seem to have started with some rainy spring weather lately.
KitoAh, but you said spring though, so that's a good sign.
BrianHopefully.
KitoYeah. It's been kind of mild here, I'm actually on the East Coast. I'm near New York City, and it's been kind of-you know, I think it's been like really cold a little bit, but mostly mild. So, who knows? I'm looking forward to spring.
Brian That's right. And the following summer
KitoYes. Indeed. I bet you it's really beautiful there in the summer, I would imagine.
Brian Yeah. Vancouver is great.
Kito Yeah. Cool. Well, I wanted to talk about a couple things here today, which relate to what you do. So, let's start out with updating people about RichFaces, I know you guys are releasing RichFaces 4.2 right now. I think CR1 came out on the 8th. And by the time you hear this, 4.2 will probably be final.

And I think what I'd like to do is..RichFaces has a very long history, started out as a product with Exadel and then has been with JBoss for quite a few years now.

And I was just wondering if you could kind of give us an overview of what happened with RichFaces 4.0 because that was the last sort of major release. And I think a lot of people have worked with 3.x or have seen an older version of RichFaces, and may not be kind of familiar with the changes in 4.0. So, why don't we start with that, and then we can talk a little bit more about the newer releases, especially 4.2.

Brian Sure. Sounds good. So, RichFaces 4.0 was primarily focused on supporting JSF 2.0. So with JSF 2.0, of course, we saw the standardization of the Ajax approach in JSF, and a corresponding change in a number of the APIs that component developers used to build components. So, with RichFaces 4.0 we ported a number of the RichFaces 3.0 components to work with JSF 2.0 and allow application developers to make a smooth transition from RichFaces 3.0 to RichFaces 4.0.

And along with that, we have a couple new features that we introduced with RichFaces 4.0. We have the client side validation feature, which brings bean validation into the browser with a JavaScript implementation. So, you can get feedback-users can get feedback on validation errors right within their browser. And similarly, we introduced the push feature with RichFaces 4.0 based on the Atmosphere Framework.

KitoOh, okay. So, there was an a4j:push component before, right? But did it use polling internally?
BrianYeah. So, what's new with RichFaces 4.0 is being based on the Atmosphere Framework, which will even go so far as to take advantage of web sockets when web sockets is available.
KitoCool. Alright. So, that was for-and I think that was what, in 2011 or 2010, maybe?
Brian That would've been May 2011, I think was the date. So, we're coming up on a year.
Kito Okay. Wow. So, you guys move fast, and they're all ready for 4.2. Alright. So, 4.1, was it just a maintenance release? Or were there any new features or anything?
Brian Right. So, with RichFaces 4.1, we introduced some more components that we ported from RichFaces 3.0. We brought in the rich editor component, which had been missing, and the pick list and ordering list. And in fact, with RichFaces 4.1, we've replaced the RichFaces 3.0 ListShuttle component, which a lot of RichFaces 3.0 users will be familiar with. We've replaced that with the RichFaces 4.0 PickList all together. So, some simplification of the components there.

We also...in RichFaces 4.1, a big feature for us was the introduction of a mobile compatibility layer for our components. We did the appropriate tweaks and improvements to our components, so they work well in a mobile environment. You can see this if you go to the RichFaces showcase with your mobile-enabled browser or your browser on your mobile phone, and view the showcase. You'll see the mobile version of the components, and how you can build mobile applications with our existing components.

Kito Now, here's a question for you while we're on that mobile topic. Do the components...do they automatically change based on the client? Or is it something that the developer has to code to say: okay, if it's a mobile device, then show this particular page reduces these components.
Brian Right. So, we have a whole getting started guide with RichFaces mobile that'll lead you through that. And you have to include some additional CSS resources when you're serving up a mobile page. What we like to look forward to in forthcoming RichFaces releases is creating platform specific renderers that would take care of this for you automatically. But some R&D work is required there.
Kito It looks like you're mostly targeting phones here. Are you targeting tablets or anything as well? Or just mostly the mobile phone footprint?
BrianWell, it's significant with our mobile compatibility of these components...it's making them enabled for touch devices. Making the buttons big enough so you can get your finger on them. Making sure they render and behave appropriately in the different environments. And we do test on both phones and tablets, so there's nothing specific to phones in here.
Kito Okay. Cool.
BrianSo, getting back to what's new in RichFaces 4.1, there are a few more things I'd like to highlight. One is we moved our code base to GitHub, which is a significant change from SVN, for those of you who are familiar with GitHub. This speaks to the community nature of the RichFaces project, and how we really want the community to be involved. And we find GitHub is-it's a great tool to enable that. Empowering end users to make poll requests...if they want to change or contribute to the framework.
Kito Have you gotten a lot of participation or more participation since you made the move?
Brian Yeah. We have gotten some community poll requests, which is great. I don't know how many of those were enabled specifically through GitHub, if they would've contributed through the SVN and patch process before. But it definitely lowered the barrier for them, made that easier.
Kito Right. Right. I know in the past, I always like-whenever I've made a change I'm like "oh man, I have to make a patch and add it to the..." it just seems like a major pain.
BrianRight. Whereas GitHub's got a big GUI button to make that easy for you.
Kito Right. That's nice.
Brian We've also moved the showcase to running on the open shift platform by Red Hat, which is the Red Had solution for virtualized platforms.
KitoYeah. I've been meaning to take a look at that myself. We actually use Amazon EC2 for all the JSFCentral related stuff.
Brian Yeah. OpenShift at some level-as you move up into the Flex tier of it-is running on Amazon EC2. So, it just provides a nice management interface for you to deal directly with your application servers, and not worry about managing the operating systems in the cloud. I'm not an expert to be speaking on OpenShift, but it's a significant change for us.
Kito Yeah. That's cool. And I remember in the old days, the RichFaces demo app was kind of slow. So, it's probably a lot speedier now. I think it was just whatever machine it was on, like a long time ago.
Brian Yeah. In the RichFaces 3.0 days?
Kito Yeah. Yeah. Exactly. Was that all for 4.1? Or was there something else you wanted to mention?
Brian Yeah. Yeah. Exactly. Was that all for 4.1? Or was there something else you wanted to mention?
Kito Okay. Well, let's move on to kind of the core of your focus, then. Because 4.1 came out in December, right?
Brian Right.
KitoWow. You guys do move fast. Okay. So now it's February, and we're talking about 4.2. That's really cool.
Brian Our goal for our pace there was to have a six-month time block release, so developers could count on when RichFaces releases are going to come out and plan accordingly. You know, not 4 restricting ourselves to a six-month time block, but that was our goal.

After releasing RichFaces 4.1, we found there were some components and some feature improvements that were missing from RichFaces 4.1 that really needed to be in the hands of developers. So, we decided to get a rush on those improvements, and improve capabilities and get RichFaces 4.2 out as soon as we could.

Kito Cool. So, looks like there are actually quite a few things in 4.2. Do you want to go ahead and start with that?
Brian With RichFaces 4.2, we've introduced some more components ported over from RichFaces 3.0. We have the context menu component, and the hotkey component, which were both missing in the RichFaces 4.0 releases up until 4.2.
Kito At this point, have you ported the entire component set or are there still RichFaces 3.0 components, which have not been ported yet?
Brian There are some additional components that have not been ported forward. And some of them, we never will port. At some point, they start solving narrowly small use cases, and our time would be better spent developing new components that solve new use cases. But we're really in tune with our community here, listening to feedback, and making good use of the JIRA voting mechanism, for instance, to help our community identify which are those RichFaces 3.0 components that they would like to see move forward.
Kito Okay. Cool.
Brian Also, with RichFaces 4.1, we've seen some-with RichFaces 4.2, sorry...there's too many "4 points" going around here. With RichFaces 4.2, we've seen some improvements to the push and resource optimization features. Lukas Fryc has excellent blog posts going into details there, which I can provide links to.
Kito Well, just take a step forward there...what do you think are the key changes that were made? If you were using the older one, why would you care?
Brian Sure. In RichFaces 4.1, we introduced our resource packaging feature, which combined all JavaScript and CSS resources into individual files for each resource type. And this enabled one to dramatically reduce the amount of resources that-when downloaded-when running JSF or a RichFaces application.

So, we improved this in RichFaces 4.2. We separated out the concept of mapping JSF resources and packaging and compressing those resources. So, what one can do now in RichFaces 4.2 is...for instance, a lot of different JSF components, or even JavaScript widgets- vanilla JavaScript widgets-are taking advantage of jQuery as it becomes a de facto standard. Well, RichFaces bundles jQuery for use with its components. And when you start using all these different component libraries and widget libraries together, you get conflicts...each one trying to load jQuery, and then jQuery just becoming unhappy with that scenario.

So, with RichFaces 4.2 resource mapping feature, you can intercept all those requests for the jQuery resource, and map them to a particular file or a particular resource that you want to serve, which would then get only served once. So, that's a great use case moving forward. Another one is if you need to patch JSF.js, if you found some bug or some improvement that you wanted to patch yourself, you can provide that component. And with a simple entry in a mapping file, you can have your resource served up instead of the one bundled with the JSF implementation.

So, those are some great improvements to the feature that we've introduced in RichFaces 4.2. We still have the packaging minification steps that we introduced in 4.1 that you can do subsequent to that mapping.

Kito So, for packaging, does that mean that you could have one huge RichFaces.js file or something? Or is it just more about how you associate the resources for a particular component?
Brian That's right. So if you enable packaging in your application, instead of getting one JavaScript and one CSS file for each component they use on the page, you'll download a single pack.js or pack.css file that includes all the resources for all the components. So, you get a single download, which would then be cached by your browser and used on subsequent pages. So, you wouldn't invoke additional downloads using your application.
Kito Okay. Cool. For the push stuff, I just wanted to move back to that for a second. Can you just mention some of the highlights? Because it looks like there's some JMS integration in there, which sounds really cool.
Brian Right. That's a...I feel, a strong feature of RichFaces is our commitment to open standards, both in contributing back to improving the standards, and also enabling the developer to take advantage of other Java EE standards as we can.

So, one area where we did that is with the push component. If JMS is available, you can have the push feature, use JMS queues for the messaging implementation. So, this is a great way of taking advantage of these high-power server side features that you have without a lot of work for the end user, or the application developer.

Kito So basically, one option would be like you have JMS queue setup, and I guess one of the endpoints is essentially the webpage, right? You could update whatever parts of the page or whatever components based on the JMS queue. In a non-Java EE environment, where say you're using a web profile or something, how does the push work? How do you basically push data back to the client?
Brian So, in most cases, pushp-the data's pushed back to the client using the Atmosphere Framework. But when you're using JMS, the messages you want to send back are queued in a JMS queue. So, you get the fault tolerant-all the goodness, if you will, that you get from the JMS technology. When you don't have JMS in your environment, you don't enable that feature. Then the messages are just sent directly via the Atmosphere Framework down to the browser.
Kito Okay. So basically, you don't have a queue either, right?
Brian Well, there is a queue to push those down, but it's not-let's see if I can remember. What makes the JMS queue special is it'll survive-if you pull the plug on the server, the JMS queue will guarantee that those messages propagate, or will continue to be delivered. There's a term for that is escaping me right now.
KitoYeah. I know that there is, too. But yeah, I don't remember it.
Brian So, that's what you get when you enable the JMS queue to back the push component. But of course, if you don't have JMS available, you're in a servlet environment or something like that, you don't have to take advantage of that.

Another place where the push component integrates with other Java EE technologies was with CDI. In RichFaces 4.1, we introduced a CDI API to allow one to create messages and push them to the browser using a CDI event mechanism.

Kito Oh, okay. And for those of you who still aren't aware, CDI is the Context Dependency Injection for the Java API, which is part of Java EE6, and can also run outside of the Java EE container. Okay. Cool. Let's see, there's also, I guess, skinning improvements that you guys have made?
Brian Yeah. In RichFaces 4.2, this was a feature that came from a community poll request, to provide a rounded corner support to the standard RichFaces skin. By simply enabling, or setting the value on a RichFaces skinning parameter, you can turn on round corner supports, taking advantage of the CSS 3 round corner...what is it...border radius property.
Kito Okay. So, were there any other things you wanted to highlight in 4.2?
Brian No, I think we covered what's new in 4.2. So, 4.2 was hot on the heels of 4.1. And we really focused on getting those new components in and those API improvements, and both the resource loading and the push capability.
KitoWere there a lot of bug fixes initially? Or is it just mostly those new features?
Brian Oh yeah. There were definitely some bug fixes. There are always bug fixes to make with every release. As users-new users-try new components and new use cases, there's always something that comes up. We do have a strong quality component to the RichFaces project, which is another one of its strengths. We have a dedicated QA team that with every release runs a battery of tens of thousands of tests to guard against regressions and so on.

We're looking at improving-always looking at improving. But physically, we're looking at improving our testing infrastructure in the coming months, and the coming releases. So, if you're at all interested in the topic of JSF testing, now is a great time to stop by our forums or weekly IRC meetings, and you can get involved with what we're doing, and look at testing the JSF applications.

Kito Yeah. And I think what you guys have done on the testing side has been very cool. Because I remember talking to Jay about this, Jay Balunas. Is he still the lead project manager for RichFaces? Or is someone else doing that now?
Brian Yeah. So I'm now leading the RichFaces project.
Kito Okay.
Brian Jay has moved onto the AeroGear project within JBoss, which is looking at mobile technologies as a whole, across different web frameworks and throughout the entire application development ecosystem, if you will.
Kito Okay.
Brian So, he's still involved with RichFaces, particularly when it comes to mobile concerns. But he's...
KitoHe's no longer doing day-to-day operations with it.
Brian Yeah. That's a good way of putting it.
Kito Okay. So, I remember...in sort of the earlier days, testing was not nearly as rigorous as it seems to be now with RichFaces. So, it seems like you guys have come a very long way in terms of getting a really, really powerful automated suite together.
Brian For sure.
Kito And actually, it reminds me of one thing. One thing I did want to ask about is the RichFaces Component Development Kit. It's probably not as well known as the project itself. Do you want to just give a quick overview of what that is?
Brian Sure. So, the CDK is the tool that we use to write our RichFaces components. This was available in both RichFaces 3.0 and RichFaces 4.0, but with RichFaces 4.0, we've seen a significant improvement in the usability of the CDK.

And in particular, the CDK in RichFaces 4.0 is really built on...it's built to have the feel of the JSF 2.0 composite component feature or technology, where one builds renderers using Facelet templates, rather than writing the Java classes. So if we look at the big picture of creating a component with the CDK, one defines a component as a class, and then you define the properties in the class, and you annotate them with this attribute annotation. And that's all you have to do to define the component. To define the renderer, we create a template file that uses the JSF 2.0 composite component templating feature as a basis, but builds on top of it with some CDK-specific extensions.

And those two files are all that's required to create a full-fledged JSF component. The CDK, at build time, will analyze your component and the annotations and what you put into that template file, and build all the required Java classes and .xml files, and all the fluff that's required to get a JSF component going. So, it's a great way to provide a new JSF component that's a full-fledged component, not a composite component.

Kito Yeah. I think the key thing I wanted to point out is that the output is not a composite component, even though the way you develop it is like a composite component.
Brian That's correct.
Kito Right. Cool. Have you found that many of your users are actually using the CDK? Because I know you guys have been-you know, you wrote some documentation about it, you've been blogging about it to try to get people outside of the development team of RichFaces to use it. What have you actually seen?
Brian Okay. We have definitely seen some use cases where users have used it. Some of our users are developing RichFaces components. We have this sandbox environment where users are welcome to contribute the components they developed. So definitely some CDK uptake for those contributing there.

And I have spoken with some individual users who have come across some bugs or limitations in the JSF 2.0 composite component technology or feature, whatever we should call that. But they were able to get around with by using the RichFaces CDK.

Kito That makes a lot of sense because there definitely are some limitations once you start doing some more complicated things. Now is the output, is it dependent on RichFaces resources, like RichFaces objects and classes?
Brian Yeah. It takes advantage of a lot of RichFaces based classes in the output that it generates. So, you will need RichFaces run core and component libraries available.
Kito Okay. Cool. There's another thing I wanted to ask you, with...well, there's probably many other things I want to ask you. But one of the other things along sort of the random RichFaces questions line is...with regards to JSF component interoperability. I know that was one of the things we tried to focus on enabling in JSF 2.0. And I know before 2.0, before JSF 2.0, there were always a couple component suites that could work together. You know, you could use RichFaces with PrimeFaces or RichFaces with Trinidad. But you couldn't use RichFaces, Trinidad, and PrimeFaces or anything like that.

What have you heard in terms of your users with using other component suites? Do you feel like it's gotten any better? Or do you feel like it's about the same? Or what?

Brian Well, that's interesting because I do get a lot of feedback about people trying to mix component sets. And it's interesting-the nature of the problem seems to have shifted to the JavaScript layer. A lot of the JSF component suites these days are taking advantage of jQuery as it's becoming this de facto standard. And as I alluded to earlier when I was talking about the RichFaces 4.2 resource mapping, jQuery conflicts can come up when jQuery is included and initialized more than once, and so on.

So, a lot of the error reports we get from people trying to mix libraries, come out of this jQuery/ JavaScript layer. So, it sounds like a lot of the problem is that the JSF 2.0 interoperability issues have been resolved, but I think a lot of that is being limited by these jQuery/JavaScript errors. And so, if we can get past that, if our resource mapping feature allows people to get past that, maybe we'll get more people exploring how the different libraries fit together. And then, we'll start to get better feedback on the JSF 2.0 improvements in that regard.

Kito That's a good point. I mean, I think we did try to do some of that with the resource handling features in core JSF 2.0. And I imagine that some of the things you do build on top of that.
Brian Definitely. Definitely building on top of what's available in JSF 2.0.
Kito Now, in terms of dependencies, is jQuery the only sort of third party dependency? Or are there other ones?
Brian At the JavaScript level, we're only using jQuery and some jQuery plug-ins. RichFaces 3.0 had a whole plethora of JavaScript libraries with jQuery being present, prototype and some UI libraries. So RichFaces 4.0 is much more...the JavaScript implementation is much more tidy in that regard.
KitoCool. Okay. Trying to think if there was anything else along the whole RichFaces line. I guess I was wonderingI'm looking actually at your roadmap here-and it looks like it says "roadmap and planning for RichFaces 4.3 and beyond." And I must admit, one of the great things about RichFaces is that you guys are so transparent with your planning and your releases and everything.
Brian Openness is very important to us. That sense of community. We want to be involved with the community as much as we can. We even go so far as to have our weekly meetings held in the open on IRC. And anyone's able to come and participate or even speculate. We have some regular spectators who just want to know what's going on with the project. And they find that a great way to get their finger on the pulse of what's going on with RichFaces.
Kito Yeah. And isn't that sort of how you got involved with RichFaces? Sort of from the community to begin with?
Brian Definitely. I initially got involved with the Seam project, and I got involved in there through the community. I had an itch I wanted to scratch, a bug I wanted to fix. I put in the patch and things quickly escalated from there. So, that community involvement is definitely a key concept that we hold dear. It was one of the principles of our project, for sure.
Kito Yeah. That's really cool. So, just looking ahead for RichFaces 4.3 and beyond, can you kind of give us an overview of what things you guys are looking at?
BrianRight. So today, our efforts have really been focused on moving RichFaces 3.0 to RichFaces 4.0-getting that component capability, enabling users to move their applications from RichFaces 3.0 and JSF 1.x into RichFaces 4.0 and JSF 2.0.

So now moving forward with RichFaces 4.0, we're going to continue to make improvements to those components. We're going to fix bugs. Some of the features-while the component is present in RichFaces 4.0, in some cases a particular feature hasn't been implemented from RichFaces 3.0-we're going to continue to make those improvements.

But what we want to look at in addition to that effort is providing a new set of components with RichFaces 4.3 and beyond. So in today's world, as everyone's probably aware, JavaScript and JavaScript widgets, as I call them, are really taking off at a fantastic pace. Projects like jQuery UI, and well there's a whole number of them to list, are providing web developers with JavaScript components that they can use in their applications to build very rich user environments, in much the way that JSF component providers have been doing for a number of years. But these are now JavaScript isolated components.

So, what we want to be able to do moving forward is take advantage of that whole ecosystem of JavaScript widgets, and wrap them using the CDK to provide full-fledged JSF components for end users. And so in this way, we hope to be able to improve our turnaround of providing users with new rich functionality in their components.

Kito Okay. Cool. And is there anything you're particularly excited about with JSF 2.2, which is supposed to be out sometime this year?
Brian Yeah. I'm really excited with what's coming in JSF 2.2. Along with the bug fixes for certain issues that I've been tracking that are key to me, the Seam Faces viewAction is going to be part of JSF 2.2, which is quite exciting. And I'm also excited that CDI integration as a whole is being looked at, with allowing CDI injection in JSF components, and other such integration concerns.
Kito Yeah. That'll be really nice. I kind of felt like the JSF/CDI integration story wasn't quite done, which was kind of a shame because that's what Seam was really doing very well with Seam 2.x. So, that's a good segue then.

You're also the module lead for Seam Faces, which I imagine you spend fewer hours on than RichFaces. So, you mentioned the view actions. Could you just explain that and just a couple of other key features in Seam Faces?

Brian Okay. So, the viewAction component...you can think of it like listening to the pre-render view event but on steroids. It provides a front controller for JSF applications. So, imagine if you come to a JSF page from outside the framework, you haven't navigated to this page through JSF, so it has nothing built up in its session to know where you came from or who you are or what you're working on. You can use the viewAction to initialize the application on entry into the application.

So for instance, you can-based on the URL or query string parameters that you're using to access the page-initialize certain backing beans, check for authorization, perform a navigation to another page. You can enable all those with the viewAction, without having to do it at the Java code level, you can do it within the viewAction Facelet tag.

Kito Okay. So, it's implemented as a Facelet tag, it's not like the old pages.xml that was in Seam?
Brian Right. That's been replaced by other features in Seam Faces. But that's not what the viewAction component is addressing. The viewAction component is specifically an action you want to execute when you first load the page.
Kito Okay. And how is that...I guess the benefit, the reason it's better than the pre-render is because it's before any real processing occurs with the page, right? Before the component tree is created and all that kind of stuff.
BrianWell, it's much more flexible. With the viewAction component, you can specify which phase you want it to execute at. So, it doesn't have to be before render. You can do it at the very earliest instance, if you choose. If you want to just, say, look at this user ID, are they allowed to access this? You can do that before the UI tree is even built-I'm sorry, before the component tree's even built-to save the resources from having to do that.
Kito Okay. Alright. That'll be really nice. I know people have been looking for that for a while now. So, what other sort of key features do you like or would you like to discuss about Seam Faces?
Brian So, we can talk about some smaller features, which I call the developer productivity improvements. But first, let me back off a step, and just reiterate that what Seam Faces is really addressing is bridging the JSF 2.0 and CDI technologies. So, it allows a JSF 2.0 developer to take full advantage of the CDI programming model in their application, without having to deal with this impedance mismatch between them.

So, some simpler developer productivity improvements are facilitating working with CDI conversations and JSF backing beans by providing the annotations @Begin and @End. So you can annotate a method with @Begin, and when that method is executed, you will begin a CDI conversation, instead of having to inject the conversation and programmatically execute Conversation.begin, and so on. And there's the analogous @End annotation, which says when this method is executed, I want you to end the conversation.

Seam Faces provides generic converters. So, this has nothing to do with CDI, but it's just a developer productivity improvement of making life easier for a JSF developer. When you write a JSF converter, you always find yourself doing a cast, right? Because you're working with objects and converters. Well, we provide some generic converters that do that casting for you. Just to make things easier.

Moving onto some of these bigger features, what I might even call the killer features of Seam Faces, we have this view config feature in Seam Faces, which is that replacement for the pages .xml you were referring to from Seam 2.0.

Bringing it back to CDI, Seam Faces allows CDI injection in more JSF classes. So, in your converters and your validations, you can take advantage of CDI injection there.

Moving on to some of these bigger features, what I might even call the killer features of Seam Faces, we have this ViewConfig feature in Seam Faces, which is that replacement for the pages.xml you were referring to from Seam 2.0.

But the advantage of ViewConfig is that it's a type safe way of configuring your JSF views. So, if you think of the improvement of CDI over Seam 2.0 is the introduction of type safety, the ViewConfig then gives us a type safe way of configuring our views that we did not have with the pages.xml. Some of the current things you can configure with this ViewConfig -it's very much annotation based-are security, you know, controlling access to your views by leveraging the Seam security module; you can do URL rewriting when you access the page, leveraging PrettyFaces; you can control the transactional behavior of that page by leveraging Seam Persistence; and you can even do something so simple as turn on faces-redirect for a view or a set of views using an annotation of the ViewConfig level, so, you don't have to write faces- redirect throughout your application.

Kito Cool.
BrianAnother key feature of JSF-or I'm sorry, Seam Faces, is bridging the JSF events into the CDI event mechanism. So, when we're in JSF land, if you will, and we want to write phase listeners or system event listeners, we have to implement interfaces and define the methods that we need to implement of that interface. Well, with Seam Faces present, those phase listener and system events are propagated into the CDI event bus. So, we can write a phase listener or system event listener as simply as writing the @Observes annotation from CDI.

So, it's a great way to take advantage of the exposure of the API that JSF gives without a lot of overhead to the end user.

KitoYeah. Nice. So, Seam Faces-is it on 3.1 right now?
Brian Right. We've just released Seam 3.1, which includes a 3.1 level of all the included modules.
Kito Right. And to be clear, there are lots of modules. Seam Faces is just one, but they can all be used independently-well, for the most part. There are some dependencies, right?
BrianWell for the most part, the only dependency really comes on Seam Solder, the core library. And then, all the other modules try to be independent-when they notice another module is present, they'll enable certain behavior. Like, you can use Seam Faces independently, but if Seam Security is present, you can use Seam Security control access to your views. So, it's ala cart.
Kito Right. Now, people who are familiar with MyFaces CODI, or with CDI extensions, may notice that the Seam Faces functionality is pretty...it overlaps to a certain degree. And so, I think that kind of brings us to a new Apache project called DeltaSpike, which includes a cooperation between JBoss folks, the MyFaces folks, and some others on some common CDI extensions.

So, I assume you're very familiar with DeltaSpike, more than me. Do you want to give us an overview of that and how that fits in with Seam Faces?

Brian Right. So, the goal of DeltaSpike is to create a set of de facto CDI extensions. This project is being worked on collaboratively by the MyFaces CODI folks, JBoss, the people who've been on Seam-there are a number of other contributors as well. I can't name them off the top of my head, but if you go to the DeltaSpike page, you can find more information there.

And the idea is to create this set of de facto CDI extensions that other projects that can then build on. We've just released the 0.1 release of DeltaSpike, which incorporates some features from Seam Solder and CODI Core to provide the basis of building further extensions. And the goal is to take all that functionality-you mentioned the duplication of functionality between MyFaces, CODI, and Seam Faces as a particular example-but we want to take all this overlapping functionality and put it into DeltaSpike as a common core, and build on that as a set of extensions that everyone can use in their project. So, we're going so far with that ourselves, that we're not going to be doing any more Seam 3.0 releases. We're focusing entirely on DeltaSpike right now.

Kito Okay. You can think of DeltaSpike sort of being like Seam 4.0, in some ways.
Brian You might be able to make an analogy that way.
Kito Yeah. I mean, obviously...
Brian I'm just going to be careful there.
Kito Well, I mean in terms of having...for those who are Seam 3.0 users, you know, if they're wondering what's going to happen to their project, DeltaSpike is where they should look for analogous functionality.
Brian Right. We are going to keep Seam 3.1 going, we might have another micro-release there to provide some bug fixes and improved documentation. People can continue to build their applications there. And then there will be a migration to DeltaSpike once DeltaSpike becomes ready for that. DeltaSpike is moving at what I consider to be an amazing pace. So, things are looking good in that regard.
Kito I'm very happy to see it too, because there's...I mean, I know there are more people than just the MyFaces guys, but I know those guys pretty well, and they're pretty bright. So, it's really nice to see you guys who are also quite bright as well, collaborate on this. I'm really kind of excited to see what comes out of it.
Brian Yeah. I think there's going to be nothing but good that comes from this collaboration, for sure.
Kito Yeah. Definitely. Well, I think those are all the key questions I had for you. Is there anything else you'd like to discuss or share with the audience, Brian?
Brian No, that pretty much covers it. I just wanted to give...make sure people know about the openness of the RichFaces project. If you're a RichFaces user, feel free to come and get involved with us. Get involved through social media with Twitter or Google+. We're active there. Come visit on us at IRC, or through our forums. Just get involved, let us know how you're using the project, how you want to see it evolve.
Kito Okay. Alright, Brian. Well, I thank you very much for your time. And hopefully, we'll get to meet again at the JAX conference and the JSF summit sessions this year. That'll be nice to get back to California.
Brian It will be. Nice and warm.
Kito Yeah. Alright. Take it easy. Thanks a lot for joining us. Appreciate it.
Brian Okay. Thanks
AnnouncerThat'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.

Resources


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.