thinking on using JSF

[Joshua Silva]

I started using Java in 2003, only if I would have taken it more serious as a web platform. Today I do most of my Java web dev in SpringMVC. It's a really simple framework etc, but I feel like since I'm not using JSF, I'm somehow loosing out.

For very simple websites we still use just straight up servlets without any framework (except what is included).

In JSF, how do you handle static content? Like say you need 10-15 pages of marketing stuff etc?

I've been thinking hard on using JSF + PrimeFaces / RichFaces for the more *application* like stuff, even then though we love flat design, than reskinning everything does take some time. After all the hype had died down, do we really need to check this out and implement it into our workflow?

Types of things we work on are pretty application like, banking, insurance, etc, but that whole flat design and really controlling it from top to bottom is a big thing for us. Would it still be wise to invest into JSF and truly understand it and learn how to customize the presentation layer as much as we possibly can? The use of those component libraries really scare me, I feel like I would be fighting the CSS for hours at a time.

Thank you for any input here, if anyone has followed a similar path.

[Bear Bibeault]

As we have a forum devoted to JSF, I've moved this there for you.

My own view of JSF is that it's a cancer that needs to be surgically excised from the face of the earth, but there are many who like it. They'll likely weigh in with their own opinions.

[Joshua Silva]

Thank you

Can't wait to hear some comments about it.

[john lazeraski]

@Bear.. why do you think it's a cancer?

As for me, I was tired of using Struts MVC and jsp scriplet code. I took a stab at Wicket as well as EXT-JS but both are more suited to administration sites, or internal apps, as opposed to large scale web facing apps. Both have a bit of a learning curve as well. What appealed to me with those two were the layout capabilities.. I wanted a Swing like layout manager so that I didn't have to worry about CSS and HTML5... of which I am not very good at. I am more mid-tier developer trying to do some front-end UI and with all the changes of the web the past few years, I've not kept up since my main job the past many years has been on the mid/back end of the platform.

So I have been slowly learning JSF. Primarily I chose it after ext-js because it's the JEE 5/6/7 standard UI framework, supported, and offers a lot of nice features. I haven't quite mastered the life cycle yet, nor can I figure out how to make more complex components. I happen to be in need of a component that can dynamically add a group of fields to the page at runtime and properly process the fields when the form is submitted. Email, Address and Phone fields, for example, where you can click a + button to add a new set of fields. Users of various types of apps could make use of this when allowing clients to add multiple phone numbers and emails without needing to pre-populate the page and take up vertical space with multiple fields "just in case". I am having a hard time finding any useful info on how to do this particular feature. With the old JSP/scriplet code, this was relatively easy, so it's a little frustrating that this task is not coming along so easy and taking up way more time than I had hoped.

Anyway, I mostly chose it because Struts is out dated, as is using straight JSP pages with scriplets and servlets, but other frameworks didn't seem to be any better or worse, so JSF being part of the JEE spec, I figured just stick with that. EJB 3.x is easy enough, as is REST API development if needed.

[Tim Holloway]

Bear is a big proponent of Do-It-Yourself webapp frameworks. I prefer to use a framework that some other poor slob has had to spend time and effort designing and debugging so that I can get on with the actual webapp design.

The problem with any framework - including DIY ones - is that it will confine you to work within its own set of rules (and some of those rules can be pretty freaky). DIY is in theory more flexible, but in practice, the more it grows, the less flexible it gets. Until you're at a par with the third-party frameworks. Which, after all, often started out as DIY frameworks themselves. The main difference in the long run is that you can find a JSF forum on JavaRanch, but not a "Bear Bibeault DIY web framework form" (so far! ) and you can buy books, enroll in overpriced courses, and even (I presume) obtain silly bits of paper certifying that your are a JSF Expert.

One of the virtues of JSF, however, is that unlike a lot of earlier frameworks, JSF is not jealous. JSF's strengths are in its ability to allow low-volume transactions using data forms and displays. When you need something that requires other forms of expertise, such as producing an Excel spreadsheet or PDF, you can drop in a bog-standard servlet or JSP into the app and JSF will play happily with it all day long. JSF will even share the world with other frameworks, such as Struts. In fact, a JSF webapp can be a mix of multiple frameworks - including the Bear Bibeault DIY Web Framework, as long as it will likewise play nice with non-framework code.

So, in short, one of the simplest and most performant ways to show lots of static content in a JSF webapp is to simply code up vanilla JSPs for them. Or, if you need some of the static content on a JSF form page, that, too is a simple matter, since JSF can pull in stuff like CSS, javascript, images, and so forth in basically the same way as any other JSP.

[Bear Bibeault]

Tim Holloway wrote:Bear is a big proponent of Do-It-Yourself webapp frameworks.

Not really.

I use all of: SpringMVC, Play, FrontMan (yes, my invention), or plain old servlets and JSP, depending on many factors. Each has their strengths and weaknesses. But JSF is not on my playlist.

john lazeraski wrote:@Bear.. why do you think it's a cancer?

To me -- others like Tim are certainly free to differ -- it doesn't solve a real world problem. I think that the problem that needs to be solved is "How do we make web applications robust and maintainable?" And JSF, in my mind, fails to solve that problem. The problem it solves is "How do we put a component framework on the web?" Which, to me, is an academic and uninteresting problem.

With all due respect to Rube Goldberg, here's my view of JSF:



But don't just take my word for it. I do urge people to learn enough about all the frameworks, including JSF, to figure out for yourself whether it's something that's appropriate to use for your project.

[Tim Holloway]

Actually, compared to other systems like Struts, JSF is simple. It's primarily based on POJOs and Inversion of Control. There's a lot of complexity internally, but it all serves to make the actual application fairly simple.

In fact, one of the biggest problems I have with JSF in this forum is trying to argue people down from doing Rube Goldberg solutions to problems that JSF was intended to make simple. They use JSF-specific methods when POJO methods would do, root around in JSF's internal data objects, muck with JSF's component tree and post executable code on what's primarily supposed to be a data file (the View Template).

[Bear Bibeault]

I'd posit that if few developers can figure out how to write JSF apps "as they are intended", it's a failure.

But again, I urge people to gather enough information to make their own informed choices.

[Tim Holloway]

Bear Bibeault wrote:I'd posit that if few developers can figure out how to write JSF apps "as they are intended", it's a failure.

Well it would be, except that they WANT to make it complex. It's not hard to figure out, and that seems to be the problem. It's apparently "too good to be true".

Apparently no one believes that a framework can be designed to work without lots of complex framework-specific code. So they use lots of complex framework-specific code even when all they need is simple generic set/get property methods, a scant handful of model wrapper classes and a no-argument action processor or 2.

Just like everyone has to design their own buggy insecure login system when the pre-debugged one that comes with J2EE is an adequate basis for probably 90% of all webapps. Which is also a well-known peeve of mine.

[Bear Bibeault]

Understood. That's a problem across the board, I've found.

And I still say you should write a FAQ on how to do web security correctly. I have yet to find a tutorial that will make things clear enough that people will actually use EE security rather than trying to role their own, and that's likely the primary problem.

[john lazeraski]

All valid points from both of you.

As for security, I started to learn the JEE container stuff and while it wasn't horribly difficult, it wasn't easy and I found myself going to google a bit to look for info on some areas. I came across a few articles pointing to Apache Shiro, and never looked back. It's not only easier to work with, but I find it easier to deal with resource protection. I did however, to be fair, find an article by BalusC on another forum who did a great write up of how to use Shiro in several scenarios. So far it works perfectly for me.. try to access any page that is configured protected, it takes you to the login page (or in my case the login button is on every "outside" page so it takes the user to a page with info on how to log in). Once logged in, it has it's own session management that uses HttpSession underneath if deployed in a JEE/servlet container, but can be used outside of the container as well. I am guessing you both have looked into it, but if not, I'd invite you to take a look, it's very nice.

[Tina Ma]

JSF is very easy to learn and use.
For static contents, you can have a directory "static" in the project directory structure, store all the static html/jsf pages in there with hard-coded code or "Application Scoped" backing beans if necessary.

[john lazeraski]

You know, I don't think JSF is as easy to learn as standard MVC frameworks like Struts. Part of that is because of all the possibilities, but also the way JSF components and lifecycle work. For me, STruts was super easy to learn.. request goes to action class, you do whatever you need, populate a request bean (or session bean sometimes), send a response string that forwards (usually) to a JSP page that provides the html output. The hardest part for me with that was dealing with the html and css and the various browser issues. But barring the CSS/HTML layout issues, writing JSP scriplet code to loop through a bean object, display it how you wanted, etc, was very easy to deal with. Granted, the management of JSP pages is a nightmare because of the mixed scriplet java code and html/css markup. It's not as pretty as a xhmtl page with JSF tags, but the trade off for me was the easy server side and lack of a tree/model on the server side that mimics what is displayed. That understanding of that is also why EXT-JS and Wicket have a steep learning curve.

On the other hand, I think once you understand how JSF 2 works, it's much nicer to work with. I feel like I am using up to date technology in my JEE6/7 apps, and hopefully as newer html/css stuff comes along, the components I use stay updated internally so that I don't have to deal with any of that. The primary driving force behind my use of JSF 2 is my lack of css3/html5 knowledge and being able to properly lay out a nice looking web page. I spend way too much time dealing with layout issues on different browsers, although that is less of a problem today than it was a few years ago.

I am still learning JSF 2, lot more to go, so perhaps once I get a good handle on it, my view will change. I liken the jsp/mvc method to that of using ruby or php to build a site rapidly. Because I can copy/paste a simple mvc/struts project quickly, I can get to work fairly quickly in building a site. It will be ugly looking, but functionally work well. To be fair I don't know ruby at all and only a little of php, but I read all the time how fast it is to use those two for web sites, and I find that I am pretty quick in assembling a site with the older jsp/struts/mvc framework.

I will add that I also want to learn new tech like JSF so that I know more than one now defunct way of doing web apps with java. I am having fun learning JSF2 for the most part.

[Tim Holloway]

The advantage of JSF over Struts is that you need fewer source files to get the job done and the MVC mapping is about as straightforward as you can get. Struts recently has also had some security issues, but that's another story.

Definitely one needs to understand the lifecycle. It's like the MVC cycle, but more fine-grained.

Unfortunately, JSF is still mired in HTML4, though. It would be nice to have HTML5 support, but not only would that require a new set of renderers (no big deal), but also some extensions to the JSF core tag attributes. Assuming you wanted to take advantage of things like HTML5's numeric-only controls and stuff like that.

You don't really need to know CSS3 specifically, although CSS is definitely something worth knowing. Ideally, companies would separate the "pretty" parts of the View design and the functional parts so that artistically-challenged people like me wouldn't be stuck creating monstrosities. JSF is, in fact designed so that artists can do the art and programmers can do the programming, but modern business "efficiencies" mandate that not only do I have to do both jobs, but also be the network admin, sysadmin and DBA.

Efficiency is overrated. When was the last time you said, "Man, that was one efficient-tasting hamburger!"