First, I really like the features being proposed, and think they will go a long way in making JSF more useful and more popular. Some people have criticized the new features as being merely a bunch of good features taken from other projects - I think this is a good way to create a spec. It should also be noted that many projects it is borrowing ideas from integrate JSF (Seam), extend JSF functionality (Facelets) or are already JSF component libraries (Ajax4JSF).
Second, I think there are a few important (or at least interesting) things that aren’t on the list:
- I kind of like the EL changes that are part of Seam, specifically being able to pass in parameters. It isn’t that hard to use a bit of a hack (ie, implementing the Map interface on an object and using that) to do this same thing in a few cases, but I’d rather see a standard and supported way to do it.
- This may be too fine of a detail, but I really wish the radio button component was a little more flexible. For example, allowing it to be used without constraining the layout, allowing it to be used easily in tables, and allowing arbitrary placement of grouped buttons on a page. I’ve created custom components to deal with this, but it would be nice to see it be a part of the spec.
At any rate, I’ve loved working with JSF over the past several years and can’t wait to see how 2.0 pans out.
Cagatay Civici has posted an example of how to quickly create a JSF slider component, built off of the scriptaculous slider widget. I like this for a few reasons:
1. It shows off an excellent use of the composition component functionality available in Facelets.
2. It shows how easy it is to create cool components using JSF - this one could be done in only a few minutes.
Hi where i can buy cheap cialis? Cheap cialis you can buy there - buycheapcialisonlinemg.com Ok, yhank you, can you sey, what prices in this shop? Oh there you can find best prices on buy cheap cialis online no prescription . Also, you can see how this component may have progressed: First as a block of HTML on the JSF page, and then likely refactored into a composition component. This is how JSF component development should proceed, in my opinion - not by creating a bunch of components at the beginning of a project, but rather by refactoring existing code into a component as needed.
I’ve spent a lot of time developing web applications in JavaServer Faces (JSF). Based on interactions with other Java developers (both in person and via the internet), I’ve come to realize there are a lot of misconceptions regarding JSF, and have attempted to address a few of them here.
1. You need to create a ton of custom components
This is perhaps the biggest misconception among people with a little exposure to, but little or no experience with, JSF. Teams can (and indeed have) spent tons of time creating custom components for a project. This is not necessary or wise.
There are very few instances where a custom component is actually required - in several years of JSF development, I can think of fewer than 5 times I felt like the only way to accomplish something was to create a custom component. In many cases, you can gain a lot of efficiency and reuse from a component and it is advantageous to create one, but this doesn’t mean you have to spend the first 3 months of a project creating them.
In a lot of cases, we’ve found that implementing functionality you are looking for without making a component first, then refactoring it into one later creates the best results. In fact, in cases where components have been built up-front, they often go unused or require heavy refactoring once someone actually uses them anyway.
2. JSF is a Web 2.0 framework
I’ve seen a few people try to compare JSF with Web 2.0 frameworks, or even characterize it as such. It isn’t. You can plug Web 2.0 functionality into it quite easily (ie, using Rich Faces, ICEfaces, or Ajax4jsf), but it isn’t specifically a Web 2.0 framework.
3. JSF is JSP 3.0
Given that JSP is used as the default templating language for JSF, I guess a few people are bound to call JSF “JSP 3.0″, but they are wrong. Granted, projects that have used JSPs in the past may replace straight JSP usage with JSF (although they may still use JSPs as the templating language), but that doesn’t mean JSF is really a successor to JSP.
JSPs are simply containers of logic, Java code (ugly!), and some tags to encapsulate other logic and presentation. JSF is a component-based, event-driven web application framework that also handles the full request/response lifecycle, validation, conversion and more.
4. You need a visual editor (or other tool support) to use JSF
I heard this one a lot, especially when JSF first came out. Yes, JSF does give greater potential for visual editors (ie, like Visual Studio), but you aren’t really required to use one. I’ve only dabbled with a few visual editors for JSF, and have not been impressed with any yet - and the design/development cycle I’ve encountered on most projects would not lend itself particularly well to this either.
There is a need for better tool support for things like code assist and refactoring, but companies like JBoss are working on this.
5. JSF constrains layout and design choices
There certainly are some design approaches that lend themselves better than others to JSF development. That said, in most cases, JSF makes it far easier to implement designs from designers and even allow them to modify JSF pages once you’ve created them - especially if you are using Facelets. In most cases, components are fully stylable and don’t add any extra HTML that would foul up a design - the radio button component being a notable exception and one case where I found it necessary to create a custom component.
This is the process I have found best for developing JSF pages efficiently and allowing the designer to contribute the most:
1. Designer creates page in proper XHTML and passes it off to a developer.
2. Developer replaces pieces of the html that need to interact with the code (ie, input boxes and data tables).
3. Designer is free to modify the layout of the page via the HTML or using CSS.
In short - there may be better choices than JSF for a particular project out there, but I feel JSF provides a lot in terms of development speed, readability and refactoring, and reuse. It is unfortunate how so many developers seem to have some weird misconceptions of it - my experience has been that once people start using it, they really like it and the misconceptions go away.
It was just last night that I posted about wanting better IDE support for JSF applications. This morning, Exadel and JBoss announced a new partnership that will open-source Exadel’s Eclipse tools and add much more support for JSF, Seam, EJB3 and more. The new tool will be called “Red Hat Developer Studio” (Red Hat is the parent company of JBoss) and will be free and open-source. Exadel Studio Pro is currently being offered with an extended free trial (which should last until Red Hat Developer Studio is released this Summer) and already has some Seam support, including auto-completion of seam components.
All in all, this is very exciting news, and is exactly the sort of thing I was hoping for when I made my post last night.
I’ve been using JSF and JPA/Hibernate for several years now, and really like these technologies, despite a few pain points involved in using them. Seam has solved most of them, except for one big one: IDE Support.
I’m not necessarily interested in GUI layout or drag-and-drop support for JSF, but I’m really interested in two things:
This may seem silly and lazy, but I lose a fair amount of time switching back and forth between my Java objects and my xhtml pages, trying to figure out what everything is named. I also make stupid typos, which is really embarrassing when trying to show off JSF and JPA in front of other people.
I guess it is more of an annoyance than anything, but it would save a fair amount of time.
This is the big one, in my book. In my opinion, refactoring is an important part of software development, yet the way we use JSF and JPA together, it is very difficult to refactor with confidence. And, since JSF pages aren’t compiled, you don’t find out you’ve messed something up until you try to use that page - and even then, it may take the proper combination of variables to see the problem. A 100% comprehensive set of web tests would fix this, but on a decent-sized project, those could take quite a while to run.
So, I’m wondering a few things:
1) What things have other people done to alleviate this problems?
2) Are there any ongoing IDE projects anyone is aware of?
3) Is this (#2) exactly why we shouldn’t be using entity objects in the view layer? I like a lot of the benefits you get from not creating DTOs everywhere, but other developers I work with have expressed concerns about the idea. The larger our project gets, the more I start to see their side of it.
JBoss Seam is, at least in my opinion, one of the most exciting web frameworks in the last several years. I’ve been keeping an eye on some interesting new features that are coming to it shortly, and here is a quick summary:
1) Spring Integration
Seam is based on EJB3, which is seen by many as a replacement for Spring. Many of us would benefit greatly from Spring integration, however, especially if we want to use Seam in current projects that are based on Spring. A colleague of mine, Mike Youngstrom, has contributed some excellent code for doing this, which is in Seam 1.1.7.
It accomplishes the following goals Gavin set forth:
(1) injection of Seam components into Spring beans, using beans.xml
(2) injection of Spring beans into Seam components using @In
(3) access to Spring beans via EL
(4) use of Seam-managed PC from Spring DAOs
2) GWT Integration
Rob Jellinghaus is working on integrating GWT with Seam (forum post). Seam already has very good Ajax4JSF support, and Seam makes using it much, much easier. It’ll be interesting to see what kind of cool stuff you can do with GWT and Seam.
The very cool Ajax4jsf project now has some excellent integration with the Google Web Toolkit, and Sergery Smirnov has written a tutorial showing how to use the two libraries together. He also states:
“The mission of the G4jsf subproject is to shift the perception of the relationship between GWT and JSF from viewing them as competitive technologies to viewing them as naturally complementary technologies.”
Interesting stuff - the Ajax4JSF library has been very useful to us, and I expect the GWT integration will be of equal quality. This opens some exciting new possibilities for using JSF and GWT.
The tutorial code is using JPA, Spring 2.0, and Facelets in addition to JSF 1.2. It isn’t required that you have this same setup, though. You could use Hibernate, iBatis, straight JDBC or whatever else in place of JPA - although you’ll want to make sure you are somehow caching the results in this case. Spring 2 (or Spring at all) is not required either, but it certainly makes things easier. Facelets isn’t required either, but if you are using JSF without Facelets, umm, why?
Lastly, I haven’t really included any configuration stuff - ie, JPA configs, faces-config, or the Spring config. It shouldn’t really be necessary.
So, first, let’s create our Content object. It can be really simple - let’s just give it a key (content key and locale), a content field, and a really simple history.
And the IdClass for it:
Now we’ll need to come up with a way to get them out of the database and onto the page. We could create a backing bean and add a property for each key, but there has got to be a better way, right? Indeed, we should be able to reference it the same way we would a normal property from a resource bundle, more or less. To do that, we’ll need to create a dummy implementation of java.util.Map. If we extend java.util.AbstractMap, we only have to implement two methods: entrySet(), which can return null for our purposes, and get(Object key), which is the actual method for getting our property.
Note how we use the locale and combine it with the key to get the object. The JpaTemplate from Spring is injected in. In the event that we can’t find an object for that key, we’ll try to return a helpful message to let the developer know what is going on. Also, in this case, I am returning the actual Content object instead of the content - this may prove useful down the road should we need to, say, show content history (or any other myriad of things, such as special formatting, etc). Here is the code for our bean:
So, now we can create our page like this (wordpress mangled it a bit - but you get the idea…):
It is relatively simple, but it will provide the basis for the next tutorial, which I will hopefully be finishing and posting tomorrow.
Ajax4jsf is an excellent library for adding Ajax functionality to your pages. It doesn’t necessarily add many new JSF components, but it gives you the ability to make your current ones work with Ajax. We’ve used it to do things like: Use server-side validation without refreshing the page, edit text on the fly, and auto-save form inputs - just to name a few.
RCFaces (Rich Client Faces) is a set of visual (and a couple of non-visual) Ajax-enabled components. While the documentation is currently sparse and incomplete, it does look quite promising and I’ll be keeping my eye on it. They have a showcase of some of their components available here. One of the things that I immediately liked was how good the components look - especially compared to a lot of other JSF component libraries.
One of the things to keep in mind is that a lot of web applications aren’t entirely Ajax-based - I personally like having the option of ‘Ajaxifying’ certain parts of a page in an app, but allowing other parts to function like a regular web page. This means it is important for Ajax component libraries to play nicely with non-Ajax components, as well as libraries like Ajax4jsf. I’m hoping over the next few weeks to be able to evaluate RCFaces and see how well it does play with Ajax4jsf, and also revisit ICEfaces to see how the two compare.
The one concern I continue to have (which has kept us from implementing it in any big projects yet) is performance, due to the large amount of overhead associated with each call. In tests, we found ICEfaces to be very responsive when doing fairly simple examples - so much so that you wouldn’t be able to tell the difference between it and a “lighter” implementation. The concern is that as you start getting any decent number of simultaneous users, you’ll see the server get overloaded rather quickly.
For this reason, we have taken a slightly different approach when building ajax JSF components and will typically process ajax requests outside of the normal JSF lifecycle when possible. Obviously, this strategy has drawbacks of its own, and there is always a bit of a tradeoff between the two.
I hope to use ICEfaces in a side project I am doing next month, and hopefully I can get a better grasp on the performance implications at that time. At any rate, the ICEfaces team should be congratulated on such an awesome framework. Keep it up!