Kito:

Hello and welcome to the JSFCentral Podcast.  This is a series of interviews, and today I'm here with Cagatay Civici, who is the project lead for the PrimeFaces Component Library for JSF.  And you're also the cofounder of PrimeFaces Technology, right?

Cagatay:

Yeah.  Prime Technology.

Kito:

Prime.  Right. I always—for some reason, I always say it like PrimeFaces, Prime Tech—I'm sure you get that a lot.

Cagatay:

Yeah.  Not many people know about the company.  It's just—usually it's PrimeFaces.

Kito:

Right.  Well, before we get started I just wanted to do a bit of a full disclosure.  My consulting company, Virtua is a PrimeFaces partner.  However, we also work with other component libraries, like ICEfaces and RichFaces, et cetera.  But I just wanted people to be aware so no one complains later—"oh, you interviewed Cagatay because you're a partner"—and that's not why. We're having the interview because this is an important component suite for JSF.  So, just so people know, you work with Prime Technologies, right?

Cagatay:

Yeah.

Kito:

So, tell us a little bit about your company. 

Cagatay:

The company was founded in 2008.  We are a Turkish company.  We have two offices: one in Istanbul, one in Ankara. Prime Technologies is currently the sponsor of the PrimeFaces project.  We do consulting, software development, trainings and things like that.  There are two areas that we are experts.  One is regular JavaEE, and the other is Agile methodologies and extreme programming.  We offer consulting trainings and regular services around these two topics.  And we have the PrimeFaces product, which is open source Apache license, and we are currently the maintainer of the project.

The company is like 25 people right now.  Five people currently work on PrimeFaces.  I am the lead of PrimeFaces; it's my full-time job.  And we have other people—it's mostly a consulting company, so we have various consultants—but we also have a dedicated team on PrimeFaces.

Kito:

Are there a lot of external committers to PrimeFaces right now?  Or is it mostly in-house?

Cagatay:

As a policy, every committer should be an employee of Prime Technology.

Kito:

Oh, interesting.

Cagatay:

Just like the Spring model.

Kito:

Right. Okay.  So, how did the project start?  Did the company start first and then the components sort of grew out of your work?

Cagatay:

Yeah.  We had been working with JSF since 2005 with JSF 1.0, which at the time wasn't very useable, but we had seen the potential of JSF, and we had started using it.  We were using other libraries like RichFaces, ICEfaces; we have used them in different projects.

But in 2008, we decided to write our own stuff, which was Yahoo UI for JSF.  And we started working on that, it was our first attempt to create a JSF component suite, but we failed after six months.  Then, we learned some important lessons, and in November 2008, we decided to create a new product for the company.  So Yahoo UI for JSF was like a regular hobby project, but it really helped us to get some experience.

And in 2008, we decided to write it from scratch and started PrimeFaces in November.  I was living in the UK back then, and my partners were in Turkey, so we were working together.  And we started the project like almost three years ago, and now we are here.

Kito:

Wow.  So, it's only been three years?

Cagatay:

Yeah.  If you check out the Google trends, then you can see that in 2009, it comes up, and it has recently become the most popular library in 2012.

Kito:

Cool.  Alright.  So I wanted to mention one topic and sort of get it out of the way.  I think it was this year or last year, there was a bit of a controversy with ICEfaces, ICEfaces 3.0, I believe.  And the issue was that the release of ICEfaces included several components, which were heavily derived from PrimeFaces 2.x.  And I think the ICEfaces—or the ICEsoft line on it was basically, they saw it as a quick way to wrap JQuery components at that time. 

But I just thought I'd put the question out there and ask you have any additional words or anything you want to say about that controversy.  I know there've been blog posts and everything.

Cagatay:

Yeah.  I mean, we have expressed on our opinions on two blog posts.  And when ICEfaces 2.0, I think it…no, ICEfaces 3.0, ACE components, they call it—

Kito:

Right.

Cagatay:

When they came out, in our community forum in our Facebook room and Twitter, I saw messages like…people who are saying it really looks like PrimeFaces.  I mean, CSS and JavaScript components. 

So, when I checked them out, I saw that they were using JQuery UI.  So, I said oh, they are using JQuery UI, so it is expected to look the same, right?  So I checked the code and their code was…well, 75 percent the same.  So before writing that blog post, we had just done some really detailed analysis, and it was at 75-80 percent the same code.  The package names were renamed… "primefaces" was renamed to "com.ice" or something.  So we did the blog posts and comparing to the panel components, which was just a nice example of copy/paste.

I mean, the whole thing…I'm not sure why they have done it.  I wouldn't have done something like that.  Actually, they approached us, like in 2010 or something, and said that they want sponsor PrimeFaces financially to incorporate some of their changes to PrimeFaces.  And we didn't like the idea of getting sponsored by a competitor because we see ICEfaces as a direct competitor, just like other Faces libraries.

So, we said we are not going to do that, and they told us okay, that's fine.  And then, after like six or eight months, they released ICEfaces ACE, which turned out to be a fork of  PrimeFaces 2.0.  So, that's when this whole controversy started; we have written this blog post announcing that it is the copy/paste of PrimeFaces 2.0.  And we haven't…unfortunately, we haven't seen enough references…I mean, this is open source, of course, this is legal because it's an Apache license and our problem has never been legal.

We have never seen enough references…at least just put some text that it is—that the code has been forked from PrimeFaces 2.0.  And after the blog post, they created two separate pages, one is a FAQ page and the other is—I think they detailed where their components originated from.  And as you can see from their page, most of them originated from PrimeFaces.

They have also copied the bugs of PrimeFaces 2.0—when I checked their showcase, I saw the bugs of PrimeFaces 2.0, but they claim that the code has been improved.  But I think that we have improved it a lot—over 1,000 changes and fixes—because the difference is huge between PrimeFaces 2.0 and 3.0.  So, I am not sure why they've done it because—I mean, they wrapped JQuery UI, right?  But they wrapped the code that wraps JQuery UI.  So, they wrapped PrimeFaces, which in turn wrapped JQuery UI.  By the way, as a side note, we are not using JQuery UI—we did just calendar right now for PrimeFaces 3.0, most of the stuff was written by ourselves with the plain native JQuery. 

So again, the weird thing for me is that it is very easy to use third party JSF libraries.  You can easily—with JSF components or if you are writing a regular component—you can just take the third party JSF library and wrap it.  So, why would you wrap another library that wraps that third party?  So, did you get my point?

Kito:

Yeah.  Yeah.  I see what you're saying.

Cagatay:

It's like two level of wrapping.  So, the guys who've done it are JSF component vendors.  So, I think that… vendor, if your product is providing JSF components, there should be some originality that… the source of the components, of course, can be third party, but it doesn't really make sense.

Kito:

Yeah.  I see what you're saying.  And I can kind of see both sides to this.  I think their argument is that—I think they're really just trying to save time because I think they thought some of—I guess they were thinking the process of the wrapping was pretty much a straightforward thing that they could save some time by sort of sidestepping that work.  And I guess the other thing they did was they integrated the ACE derivative components into the ICEfaces Ajax framework, which works differently than PrimeFaces. So now, I think of them as being different components, right?  Because now your PrimeFaces 3.0 components are very different than PrimeFaces 2.0 components. But yeah, it's sort of an interesting scenario there.

Cagatay:

Yeah.  I mean, again, what they have done doesn't make sense at all to me.  If I would wrap a third party library to speed up the development time…we have done it in PrimeFaces 1.0 and 2.0 because the other libraries were well established, because PrimeFaces is like four years younger than other libraries.  But again, wrapping another JSF component suite doesn't make sense.  And they claim that they have improved it, which I actually have never seen because the bugs are still there, from PrimeFaces.  And they are offering commercial support and things like that, they tried to get some customers, but they claim that they are contributing back to open source, which I don't buy.

Kito:

Right.  Alright.  Well, we'll leave it there.  And I think in the future, we'll try and get someone from ICEsoft back on here because we haven't recently done an interview with them.

Cagatay:

Yeah.  I've tried to reach them for like four months or something.  I'm just sending emails, trying to get someone to discuss, but no one is answering.

Kito:

Alright.  Well, hopefully we'll get someone on the show eventually.  That would be good. 

Okay.  So, one of the things you did mention was JQuery, right? 

Cagatay:

Yeah.

Kito:

So, I just wanted to talk a little bit about that.  I've been working a lot with it lately, it's a great library.  But there's lots of different parts to it, right?  So, obviously you still use it heavily, but can you explain how JQuery's involved in the PrimeFaces project?

Cagatay:

Yeah.  Actually, the thing started with Yahoo UI, and we were in PrimeFaces 1.0.  It was based on Yahoo UI.  So, every widget was a wrapper around the Yahoo UI library.  And then, I guess it was…after 2010, I guess—I can't really remember the date…JQuery was becoming really popular, and we were really excited about—when we first integrated JQuery for our Ajax stuff in PrimeFaces.  And we decided to keep the visual stuff with Yahoo and the core scripting with JQuery.

And then, JQuery started to take over PrimeFaces.  One component by one.  So, we realized that and the popularity…I mean, it's the de facto standard.  It really makes our jobs easy, my life easy as a component developer.  So we decided to drop the Yahoo UI stuff, and rewrite all of the Yahoo UI counterparts with JQuery.  So, luckily we had JQuery UI, for example, we replaced the Yahoo UI dialogue with JQuery dialogue and things like that because they were similar components.

And still we were mostly wrapping third party libraries, which were JQuery UI, a bunch of JQuery plug-ins.  So PrimeFaces was becoming a quickly evolving library, but it was kind of dirty because we have incorporated lots of different works from different people who do not know each other.  And we were trying to make their work together work fine.  So, we have started to face some problems—not some problems, but a lot of problems because these third party widgets are not designed for JSF.  Most of the JavaScript libraries usually work with JSON or XML, and JSF just likes content, right?  The components render HTML and things like that.

And there were some mismatches. And after that, we realized that by wrapping these third party libraries for over a year…all of a sudden we realized that we had gained the ability to write our own widgets, so it was kind of weird that all of a sudden, you realize that you gained some skill, which is writing your own widgets.

And that is one thing that I have changed.  I believe things that have changed in PrimeFaces, that is why it is so popular right now because we write our own widgets. For example, if a customer or a community member or we want something from the widget, we can just edit.  If you were using a third party library, that was probably not very easy and difficult, sometimes impossible.

That is one of the biggest advantages of JQuery, and right now we are just also leaning away from JQuery UI libraries or third party—anything visual.  We are just trying to avoid that.  And we are writing our stuff with plain JQuery.  So, we are still using JQuery, but accessing elements and appending content or Ajax or things like that, or finding elements using JQuery selectors.  But we are writing the visual stuff ourselves, of course adding CSS on top of it.

Kito:

That brings me to another question.  One of the things, which is a little different about PrimeFaces versus other component libraries is that the Ajax transport layer is actually done via JQuery instead of using the built-in JSF 2.0 Ajax.  Can you explain why you made that decision?

Cagatay:

We had some problems with the core implementation's Ajax updates or things like that.  And we had to extend them in some places.  For example, when we were testing f:ajax, for example, to update some components, the JSF implementation sometimes wasn't enough.  So, sometimes it couldn't update the component, it got JavaScript errors.  Of course, this was a time when we were migrating to JSF 2.0.  So, of course, they are much more mature and easy right now, but also we have extended JSF—our own implementation, it's like custom Ajax behaviors and things like that. 

So, that's one of the reasons that—of course, we are just using the same parameters.  There's nothing different on the server side.  We are just using JQuery to serialize the form and make the Ajax requests.  When we compare JQuery's usage or performance tests with a JSF implementation, it is, of course, much more used and much better tested in cross-browsers and things like that.

So, everything is the same; the same parameters are sent and the same parameters are received.  PrimeFaces is not doing anything on the server side to handle Ajax; just the script that makes the Ajax call is different. 

But in regular JSF, for example, if you use f:ajax, the PrimeFaces Ajax Status component is triggered as well.  Well, with the new release. 

Kito:

I didn't know that.  Okay.

Cagatay:

Yeah.  We have just committed that yesterday.  But there are many integration points that we hook into regular JSF implementation as well.

Kito:

Okay.  So, does that mean that you can use the f:ajax hooks with the…

Cagatay:

Yeah.

Kito:

Oh really?  Cool.  Alright.  That's good to know. 

Alright.  Another sort of JQuery related topic is PrimeFaces Mobile.  Do the Mobile components wrap JQuery widgets right now?

Cagatay:

Yeah.  They wrap JQuery Mobile.  We have just done some research on this topic, to find out if we should just provide our own widgets or find a third party mobile platform and add some JSF magic on top of it. 

So, we have decided that if we are going to write our own mobile stuff, it would be better to separate it and just offer it to everybody else, not for JSF users, like Prime Mobile or things like that.

But you realize that we are already using JQuery's stack, which is on PrimeFaces powered by JQuery.  And when we did some initial tests with JQuery Mobile, it was very promising and still very active.  So, we have decided to build a mobile render kit based on JQuery Mobile.  So, for example, if you have a command button—p:command button—if you open that on a desktop browser, it just displays as a regular button.  But on a mobile device, it is using JQuery's button CSS or things, so, that it displays in an optimized format.

So, we are using JQuery Mobile as a render kit.

Kito:

Oh, interesting.  Okay.  Makes a lot of sense.

And so, in the showcase, PrimeFaces Mobile has a separate version number and everything.  Is it a separate download or is it just included?

Cagatay:

Yeah.  It's a separate project, 0.9.3.  There's a compatibility matrix, for example, this version works fine on PrimeFaces 3.3.  So, to get PrimeFaces Mobile, it's a separate project, it has a separate user's guide, separate JAR, and everything.

Kito:

Alright.  Great.  So, another sort of sub-project is PrimeFaces Push, right?

Cagatay:

Yeah.

Kito:

And I think it is—as of right now, and this is July 2010—I'm sorry, 2012.  July, 2012—

Cagatay:

We actually did a podcast in 2010, right?

Kito:

Yeah.  And as of right now, the Push feature for 3.3 works using Jetty and only worked with sockets,HTML5 Web Sockets, right?  But I think you're making changes for future releases, right?  So, want to talk a little bit about that?

Cagatay:

Yeah.  Thanks for bringing that up because that is a topic that I really want to talk about. Monday, we made a blog post introducing the new PrimeFaces Push, which is coming out in 3.4.  The current Push before the prior Push framework is based on web sockets only, and there's just tons of limitations…it was just the proof of concept. 

It works, but I mean, I have never seen someone using that in production.  It's just for…like a fun module, but…

Kito:

You know, I did see someone in the forums that… They had like Jetty running inside the web application, and I thought that was kind of cool.

Cagatay:

Yeah.  So, the problem with Push is there are lots of browsers, lots of containers.  There is no Web Sockets API for Servlets.  I think there's a JSR, right?  But it's not standard.  So, we have decided to make a change for 3.4, and we have decided to integrate Atmosphere in our framework. 

So, we were actually the first adopters of Atmosphere back in 2010.  Atmosphere was in 0.3, it was a new beginning for the project.  But due to lack of documentation and some problems, and also, we couldn't get things right with the integration.  We had some problems and we have decided to use plain web sockets in Jetty.  That didn't work out very well.

So, we tried it twice but couldn't get it right.  But the third time, we decided to get an expert, Jeanfrancois Arcand, who was the Atmosphere framework's founder, and a good friend as of now because we invited him to Istanbul on the beginning of July 2012. 

So, he was very kind and he was available, luckily, and he accepted our invitation.  He worked with us for one week. We had really a good time because he was a great guy, top-notch developer, and it was a pleasure to work with him.  So…Atmosphere framework…there are various frameworks integrated with it.  For example, RichFaces is also using Atmosphere, I think GWT is.  Atmosphere has been used on various Web sites, including the Wall Street Journal or more—also, other Web sites. 

So, Atmosphere just fixes the main problem of mismatch because we have lots of containers: Jetty, Tomcat, Glassfish, Web Logic, Web Sphere.  Each has different web socket APIs, if they spent—it's like a proprietary.  So, also IE doesn't support web sockets, Firefox sometimes behaves funny because they have more web socket options.

So, we needed a framework and Atmosphere handles this by bringing compatibility with a graceful degradation.  For example, if the web sockets are not supported, it falls back to long polling or streaming or SSE, or other transport techniques.  And it also handles…it's portable—whenever you deploy Atmosphere, it will choose the necessary APIs. For example, it can understand if it runs on Tomcat, JBoss, or Jetty.  It just picks the right API to use, both on the server side and the client side. So, it will support scaling, you can use Hazelcast or other projects to scale your Push infrastructure, distribute your broadcasters and so on. 

So, in short, Jeanfrancois is the architect of PrimeFaces Push.  We have just taken care of the JSF part of the things.  And he has written the PrimeFaces Push architecture.  And he implemented that model.  And we have just taken care of the JSF components stuff, and so on.

So we announced it on Monday, like, two days ago.  We have added lots of new demos, like location base check-in sample, where you can get your location from Google Maps and send where you are to other subscribers.  There's a nice chat sample, Twitter search streaming sample, you can Push Faces messages to everyone and things like that.

So, PrimeFaces Push runs on Atmosphere, on top of Atmosphere, and it provides integration with JSF because if you are going to use Atmosphere—because this is such an advanced topic—it is not easy.  As Jeanfrancois said to me that it will always be Atmosphere with something.  So, in our case it is Atmosphere, with JSF with PrimeFaces.

Kito:

Oh, so it's uncommon for someone to just Atmosphere by itself is what you're saying.

Cagatay:

Yeah.  I mean, if you are using a framework, most of the frameworks have integration with Atmosphere. It's quick, and recently, it's becoming the de facto standard because it fixes one of the biggest problems of the JavaEE and Push, which is this mismatch.  And usually, there's a framework available.  Atmosphere has modules for GWT and Wicket and things...and PrimeFaces.

So, of course, you can do it.  You can write an Atmosphere handler, you can use the JQuery plug-in of Atmosphere.  But it will be easier if you're going to use PrimeFaces Push because it is integrated with the JSF programming model, because you can just push from a JSF action.  So, for JSF users, it is much more comfortable to get started with Push and Atmosphere.

Kito:

Right.  So, that's coming in PrimeFaces 3.4.  As of…what day is this recording…it's July 19th we're recording this. 3.3 is the most—3.31 is the most recent release.  What's sort of the timeframe for 3.4?

Cagatay:

Currently in maintenance state, no features.  So, it's implementing...I mean, we have already implemented the requirements of the PRO users, committee users in our plans.  So, we are just doing maintenance right now.  I think it will take two weeks to finish the maintenance and bug fixes, and we will hopefully release by early August.

Kito:

Okay.  So, 3.4 is out sometime in early August.  Are there any plans for 3.5 yet?  Or is that still sort of being planned out?

Cagatay:

Actually, we would like to focus on PrimeFaces Mobile after 3.4, because that was to bring production into Push, create new components, improve the library in general.

And now, we would like to focus more on PrimeFaces Mobile because we have lots of plans for Mobile, like lazy loading of views, improve resources, reduce band width.  More Mobile components, for example, like calendar, because in Mobile environment the calendar doesn't display optimized and things like that.

So, I think after 3.4, we will focus on PrimeFaces Mobile and do a release.  And then, continue with PrimeFaces 3.5.  In the meantime, PrimeFaces will be in maintenance mode after 3.4, while Mobile is actively developed.

Kito:

I see.  Okay.  Another area we didn't discuss yet was the PrimeFaces theming, right?  So right now, with PrimeFaces you can create different themes using—what's it called?  The JQuery ThemeRoller, is that what it's called?

Cagatay:

Yes.

Kito:

Yeah.  So, do you want to talk a bit about that?

Cagatay:

It's one of my favorite features.  So, we didn't have a skinning mechanism in PrimeFaces 2.1 or lower releases.  Then, we had decided to integrate the JQuery ThemeRoller.  ThemeRoller is like a generic theming framework, it defines, it separates structure—like paddings and margins—from skinning, which is colors.  And it defines a series of skinning selectors like content, header, state selectors like active hover, and things like that.

So, we have decided to use ThemeRoller, and right now, we are developing new components and the components we have developed using these CSS classes.  So, when we develop a new component, it is already integrated to themes.  This is quite flexible because the components do not know about their colors.  When we were working with other libraries, this was a major problem.  For example, we had this panel component, and tried to change the background of the header.  So, we had to find which panel class, like panel header, is providing that header color.  But with ThemeRoller in PrimeFaces, users do not need to know about each of these component specific CSS classes because it's unnecessary, and because all these skinning classes are global.  So, this is a major difference. 

And we have this theme gallery; I think we have 35 themes right now and counting.  People are also contributing their own themes.  And it's quite easy and fun because you don't need to know CSS to create your own themes, you can just go to the ThemeRoller and design your own theme.  I know people who designed their themes with their clients, so clients can see the colors instantly, and they don't need to know about CSS at all.  They just need to download that theme from the visual designer, and create a PrimeFaces theme out of it, and that's it.

So, PrimeFaces Mobile also has—because JQuery Mobile also has—integration with ThemeRoller.  So PrimeFaces Mobile also supports themes. More themes are coming up in the future.  We had some idea of offering premium themes, like created by our Web designer, but it is on hold at the moment, and we will see how it will go.  But it's one of my favorite features.

Kito:

Yeah.  And I agree.  It does make it a lot easier when you have a certain set of CSS selectors that you know are going to work across the different components.  If you create a new theme using ThemeRoller, do you have to create a separate one for the mobile stuff, or is it just the same theme?

Cagatay:

I think it's different.

Kito:

Okay.  Okay.  Interesting.  One other thing that I forgot was in 3.4—I think you're adding better support for portal servers for portlets in 3.4?

Cagatay:

Yeah.  3.4, we are trying on that because Neil Griffin, who is the lead of Liferay Faces.  He was the lead of Portletfaces, and now after moving to Liferay, the project has been renamed to Liferay Faces. I know there are many people who are using PrimeFaces and Liferay, but we are trying to make their life easier, and we are in contact with Neil sometimes like—I guess, like last month we had a Skype talk with him to go over issues.  And usually, he is kind enough to provide patches himself.

So, that is something we are trying to improve because on portlets, we have requirements or demands from the community asking for better portlet support.  So for PrimeFaces, portlets are also important.  So, that is an area we are working on. For PrimeFaces 3.0, for example, there were a couple of features like data export support for portlets, or running multiple PrimeFaces portlets on the same portal page.  So, these are the two outstanding issues right now, which we are hoping to solve by 3.4.  If not, we will solve them in a future release.

Kito:

Have you had a lot of requests for people using PrimeFaces and portal servers other than Liferay?

Cagatay:

Not really.  Most of the time, Liferay.

Kito:

Interesting.  Okay.  I do a lot of Liferay work, so I was just curious to see what else people are using out there.

Alright.  So, you mentioned earlier that your PrimeFaces PRO users had added some features and everything.  And I noticed in your blog sometimes you say okay, a PrimeFaces PRO user added or wanted this new component or something.  So, can you tell us a little bit about your PrimeFaces PRO offering and what that is?

Cagatay:

Okay.  So, the PrimeFaces PRO is not a separate product; PrimeFaces has only one license, an Apache license, it's a free product.  But in case companies need support, like enterprise commercial support, we call it PrimeFaces PRO.  So, the people who subscribe to this service, they become PrimeFaces PRO users.

So, it has various advantages; for example, the PrimeFaces PRO user does not need to use the PrimeFaces community issue tracker to file a bug or feature requests.  We have separate JIRA applications at pro.primefaces.org where we provide a username and password, and they can login to the system and create issues.  And we respond, at most in one business day.  It is usually like a couple of hours, our team responds to that. So, whenever they suffer from a bug or report a bug, we fix it as soon as possible.

For our feature requests, we tried to implement the requests in the next major release.  So if you follow the PrimeFaces blog, most of the features of PrimeFaces 3.4 are requests of PrimeFaces PRO users.  We also provide private branch management in case—for example, if a PRO user has an application in production and they don't want to upgrade to a newer version of PrimeFaces but need to get some fixes, we provide branches as well and backport fixes if we can. 

There are an unlimited number of cases: remote desktop connection, we do code reviews, conference calls, and also offer non-PrimeFaces related JSF assistance.  This is term based, three months, six, and one year.  And it is hourly based, so whenever a PRO user subscribes, we provide support hours, like 20 hours and 30 hours.  And they can, of course, purchase more hours if they need during their term.

So, this is—we currently have 25 PRO users, mostly organizations and corporate.  So, the PrimeFaces PRO is quite important for the PrimeFaces project because it's the commercial side.  And the good thing is that what PrimeFaces PRO users contribute to the project, the community also benefits from that, because everything done in PrimeFaces PRO is also available to the community for free.

Kito:

Right.  I think that's one of the good things about the Open Source model.  Definitely. 

So one of the things that often happens in projects is the developers want to use more than one component suite.  And I know that for JSF 2.0, we tried to make it so that the component suites worked better together.  Have you seen a lot of people using PrimeFaces and another component suite like RichFaces or something else?

Cagatay:

I've actually never seen someone in our forum doing that. 

Kito:

Really?

Cagatay:

Because I think they won't need other libraries.  Because the ideal PrimeFaces is providing everything they need.  So, I think they don't need any solution on other libraries that they don't see in PrimeFaces.  It's usually the other way.

Kito:

And you're saying usually there is some library they are using, and then they want to use PrimeFaces with it?

Cagatay:

Yeah.  Because I think—the problem could be JQuery because I think RichFaces also uses JQuery.  So, if you have multiple JQuery…that could be a problem.  In the past, with JSF 1.0, it was on the sever side problems with all these renderers, navigation handlers, Ajax blah blah handlers.  But now, I think the problem with JSF 2.0 is on the client side.  But I think it's quite easy to fix by just making sure only one JQuery is included.  But again, for example, if RichFaces is using JQuery 1.7 and if PrimeFaces is using 1.8…there could be some compatibility problems.  I think ICEfaces will work fine. 

Kito:

So, one of the component libraries that are out there that does work well out of the box with PrimeFaces is the PrimeFaces Extensions component library, which is a set of JSF components that are built sort of on top of the PrimeFaces infrastructure. So, can you tell me a little bit about that project and how it's related to the official PrimeFaces project?

Cagatay:

Yeah.  Sure.  PrimeFaces Extensions is a community-driven project led by Oleg and Tomas, who also contribute to PrimeFaces a lot.  And I think the Extensions projects have like more than 20 components.  For example, in PrimeFaces, we have a BlockUI. In Extensions projects, there is also a BlockUI.  So, there are also extended components, plus new components that you cannot find in PrimeFaces, like CodeMirror and things like that.

So, I think they are doing a great job, and I've seen more…the momentum is really great, for example, their forum is also inside the PrimeFaces forum.  And we have direct links on primefaces.org, so it's the official Extensions project.  And PrimeFaces Extensions project is also using PrimeFaces internal APIs, so those guys really know the internals of PrimeFaces really well.

And the releases are already scheduled, so whenever we do a PrimeFaces release, they do a release as well, just to make sure it's compatible.

So yeah, that's it.  And PrimeFaces extensions, they have a showcase, and they have Mojarra and MyFaces showcases.  Lots of cool stuff.  And there are a couple of things they really do well…they really provide nice solutions. 

Kito:

Yeah.  And I think that if you are using PrimeFaces, it's probably the first choice if you need…if there is some component that is missing…because you know it works well with PrimeFaces.  They have a different strategy though, because they do wrap some JQuery widgets, right?

Cagatay:

Yeah.

Kito:

Because I've noticed, I've worked with a couple of their components and they sometimes were just wrapping JQuery.  So, it's sort of a different strategy there.

Alright.  So, I just wanted to spend a couple of minutes on sort of straight up JSF talk.  JSF 2.2 is under development now and it's been at least a year, I think, we've been working on it.  And there's several different features that are coming out; there's a multi-templating support, there's task flows, or sort of like Spring Web Flow sort of flows, and HTML 5.0 support. Is there anything in particular that you're excited about with JSF 2.2 or is there something that you want to make sure is going to be in there?

Cagatay:

Yeah.  I'm quite happy with the multi-templating and task flows.  Also, page actions.  And I think having HTML 5.0 stuff from my perspective, it's okay.  But I mean, it's a bit late anyway because people can use HTML 5.0 stuff already with PrimeFaces, so it's not really vital.  But of course, JSF itself should provide those out of the box. 

But I wonder about the fallbacks.  For example, in HTML 5.0, we had this placeholder for inputs.  But in PrimeFaces, we have fallbacks for browsers that do not support those HTML 5.0 attributes, so it falls back to JavaScript.  So, I'm not really excited about the HTML 5.0 attributes like placeholder or type because people are already using that in PrimeFaces for a long time, but I'm quite excited about the page actions and task flows. 

One thing I would like to see is that whenever I compare JSF with other libraries, people would like to see it more lightweight.  I think there are many people who would like to generate or program JSF using just Java, not with XHTML or things.  So, that they would like to see generating of views done easily, like new HtmlInputText(). Like in Wicket or GWT.  Because not everyone is a web developer, and I'm sure the people who like Wicket or GWT or other similar frameworks are—they have some server side background, not UI front end backgrounds.

So, I'm fine with the XHTMLs because I actually prefer separating views with the model.  But I know there are people who would like to do it the other way.  So, I will be happy if that's easier.  I think Ed started the project—

Kito:

Yeah.  He did.  It's called—I don't know, it's called Views or something.  I don't remember.

Cagatay:

I think he's right now he's busy with the spec.  So, that's one part I would like to see in JSF. 

Also, time is moving and people are trying new things, like using no server side framework at all. Like just using JQuery doing like web services calls, getting the data, because JAX-RS is quite easy with JQuery and you can bind your client site to a RESTful Web service and get the data and push the data, so there is no server side framework, or server side rendering at all. So, I wonder how that would fit in PrimeFaces because on 2.0 there were things, we are getting some requests like how can we bind a PrimeFaces component to a JAX-RS service or things like that.

Kito:

I see.

Cagatay:

For example, because most of the time, the web service will provide JSON or XML, and what PrimeFaces or JSF needs is some Java class or some content.  So, that's something in PrimeFaces we will just work on, I'm not sure how that will resolve, like binding a PrimeFaces data table to a JAX-RS URL or something.  But that's something I would like to see in JSF, more lightweight—I mean, it's architecturally different, but I wonder how that will play because I've seen a blog post recently comparing web frameworks and one of the criteria was using this external data sources and things like that, which JSF doesn't provide a built-in solution.

Kito:

Yeah.  I mean, I think there definitely is a segment that's really interested in that, you know?  Not everyone has IE9 or the latest version of Firefox, but you can do a lot on a client, and so then, I think the question becomes, number one, how much of your development is going to be in JavaScript versus Java.  And then, if you are just building a set of RESTful services, how can you consume those?

And I still think even if JSF has a lighter-weight model, I still see a lot of value in sort of being able to specify the components and their relationships on the server.  And then, pushing those to the client and then, sort of being able to decide what things are client side and which things are server side. So, yeah.  It will be interesting to see what happens with that.

Cagatay:

Yeah.  Well, the interesting thing is that we are already using that in PrimeFaces.  For example, if we can do the same thing on the server side and the client side, we usually prefer doing that on the client side.  Most of the markup on PrimeFaces can be generated on the client side, for example, if you take a SelectOneMenu or Autocomplete or various components that have overlays, where the dropdown displays an overlay or dialogues.  We just generate the markup on the client side because it's much easier, of course—with JQuery, we just correct divs and spans and inputs, and appends and prepends, so we can do DOM relocation as well.  And on the server side, of course, rendering things it will take some time.  So, we are trying to do that more sort of things on the client side.  This includes rendering as well. 

So, JSF is getting there, but I'm not sure if JSF is a good fit for that.  We will see.  But of course, components libraries can do that, even if JSF core doesn't provide something. 

Kito:

Well, I think you're right.  And I think also, it is pretty easy with PrimeFaces.  You know, there's the RequestContext, you can send an object back.  I've done some work before where we're sending JSON back and forth. So, you can certainly do it.  And we've used that in some cases where it makes more sense to send JSON, and that's what we want. 

And also, I think there is an argument that although you could send the whole UI down to the client and do everything in JavaScript through CSS and REST, I don't think that works in all browsers, in all machines yet.  And it's a different skill set for Java developers to do the entire UI in JavaScript.  For better or worse. 

Cagatay:

Yeah.  I think to sum up my perspective of JSF is it's really excellent for really rapid application development because I can really quickly come up with a great looking UI in an hour with PrimeFaces.  So I can just create data tables—themes and skinning, filtering, sorting, paging—all these are built-in. 

I worked with a project—I was using Spring MVC and plain JQuery—I think it was last year. It really took a lot of time to do some pagination—server side pagination and things like that—doing some Ajax.  So, of course it has advantages, like stateless web applications.  But JSF really adds a great value to wrapped application development. And this is why I think it's so popular, it's just easy to create nice looking UIs in no time.

Kito:

Yeah.  Definitely.  And the integrated server side binding is always really nice.

Cagatay:

Yeah.  I mean, not many people are a fan of JSF...for example, when you see a blog somewhere saying that JSF is not a good framework or there are some better alternatives…  And of course, it's not a silver bullet, but when I add the PrimeFaces community to other component libraries communities, regular Mojarra, MyFaces… There are lots of members in the JSF ecosystem, and if you just sum them all up, it will be a giant community.  And it's just popular.

Kito:

Yeah.  I was going to say I don't think it's necessarily that a lot of people don't…that it's unpopular at all.  It's just that there's—it's just that the distracters are very loud.  And also, I think JSF does suffer a bit from the J2EE phenomenon where the first release wasn't so strong and got a lot of bad publicity.  I think if JSF 2.0 were the first release, there'd be just a very small number of complaints. 

Cagatay:

That's right.

Kito:

Alright.  Well, I think that's about all the questions I had.  Is there anything else you wanted to add?

Cagatay:

Let me see.  I had this FAQ page open on my screen, so trying to see if we had missed something.  Maybe we can talk about browser support in case people are wondering, or…

Kito:

Yeah.  And I think that one of the number one features that a component framework provides is testing it in different browsers.

Cagatay:

Most of our stuff works fine on WebKit—Safari, Chrome—and Firefox as well.  We support Firefox starting from 3.6, which is like a really legacy Firefox.  And we support Safari from legacy—I can't really remember the version right now.  And Chrome as well.  And the most important thing is IE, which is we support IE from 7, we don't support IE6, and luckily, we don't have anyone asking for IE6 support in the community.

Kito:

Really? That's great. 

Cagatay:

Yeah.  I was very surprised, but that's a good thing.  And IE7, 8, 9 and 10, it will go like that.  By supporting, I mean, if something breaks, we will fix it.  But that's not the case with IE6.

Also, maybe I can just briefly talk about cloud support.  We have a sample running on Google App Engine, and also, we have worked with the Jelastic guys and they have created a tutorial on how to deploy PrimeFaces applications to Jelastic cloud.  And JSF and PrimeFaces support cloud applications as well, in case some listener is wondering about that.

So, to sum up, I have some small announcements for 3.4, which is we are missing support for Maven Central.  We are trying—we will try to deploy PrimeFaces 3.4 to Maven Central, and we will try to get rid of our own custom repository so that PrimeFaces artifacts will be in Maven Central repository, and snapshots somewhere else.

Kito:

Just out of curiosity, Cagatay, how do you get your artifact into Maven Central, what's the process?

Cagatay:

I'm not an expert on that, but I think you need to create a JIRA ticket with your Open Source project references.  And I think there's some—the documentation is pretty good, but it all starts with the JIRA ticket. 

And PrimeFaces Extensions is also in Maven Central, so they were trying to convince us that PrimeFaces is up.  And also, other users because they are using Nexus and other things, which in some corporations and companies, I think they do not allow some custom repositories, so everything should be in Maven Central. So, that's one of the reasons that we are trying to push, but it will take a couple of days, I guess, for us to go through that process because we are not very familiar with it.

So, I think that was it. Just again, to sum up, if you are following PrimeFaces, just join the community; we have a Facebook group, which is like 2,500 people.  Community forum is there, if you need support, there are like more than 10,000 people there.  Just follow PrimeFaces on Twitter.  It is one of the most active projects regarding development.  We usually do three, two or three posts every week, to demonstrate the new features.  So if you are using PrimeFaces, these are the necessary steps in case you'd like to monitor the project, what's going on. 

So socially PrimeFaces quite good.  Also, I forgot to mention, PrimeFaces also has two native mobile applications.  One is for Android, and one is for iPhone, which you can just download from the Android shop or app store.  And you can just track PrimeFaces news and development from your mobile phone as well. 

Kito:

Oh really?  I didn't know that.

Cagatay:

It is really original, which you cannot find in other projects.  We also created these movies as the trailers for the new versions, and new trailers coming up for 3.4.  So, stay tuned for 3.4, that's all I'm going to say.

Kito:

Okay.  Alright, Cagatay, well, thank you very much. 

Cagatay:

Well, thank you Kito for having me.