3

I have the option of doing my next project in either JSF or JSP. Other languages/frameworks are not an option.

I don't want to use any of the visual component libraries like RichFaces, IceFaces, etc, because in the past I've had very bad experiences with them, so I'll be cherry-picking jQuery components to do exactly what I want them to do.

Similarly I won't be bothering with data access components.

Moreover since JSF comes with many restrictions over JSPs (e.g. no support for GET, cannot avoid being stateful, etc.), I'm considering going JSP+Beans all the way.

Are there any other things I'll be missing from JSF?

Kay Pale
  • 6,449
  • 7
  • 28
  • 28
  • 3
    Yes, you missed release of JSF 2.0. Related: [What are the main disadvantages of JSF 2.0?](http://stackoverflow.com/questions/3623911/what-are-the-main-disadvantages-of-java-server-faces-2-0) Since you seem to be more jQuery oriented, rather go for a request based MVC framework instead of a component based MVC framework. Related: [What is the need of JSF when UI can be achieved with jQuery?](http://stackoverflow.com/questions/4421839/what-is-the-need-of-jsf-when-ui-can-be-achieved-from-css-html-javascript-jquery) – BalusC Jan 12 '11 at 18:32
  • 4
    I would go with plain old Servlets+JSP. Things get out of your control pretty easily with JSF. Hate it. Not putting it as an answer since it's subjective and argumentative. :-) – Pablo Santa Cruz Jan 12 '11 at 18:32

1 Answers1

1

The restrictions you speak of are not really there. JSF absolutely supports GET. It has in fact always supported this, although with some limitations. What you did was injecting #{param.some_id} into your bean and taking some action in a @PostContruct annotated method.

With JSF 2.0 this support has been greatly expanded and you can attach standard validators and convertors to them, something you couldn't do in JSF 1.x.

The advantages of JSF are many, but one particular thing I missed when doing plain JSP development is having a library of convertors and validators available. No matter what kind of web development you do, and no matter how fancy your client-code is, eventually some operation has to be performed on the server and then you have to do conversion and validation.

With JSF you can easily build your own library of those convertors and validators, or choose from many of the ones that are already available. With bean validation (Java EE 6) this can be taken to the next level: annotate your entities with constraints and JSF will enforce those for you in the UI. (note that JSF itself doesn't contain bean validation, but it supports it).

Then I also found that having a simple but effective templating language can be very helpful. Even if you only use few or maybe no JSF components at all, you can create master template pages, have template clients and put your jQuery based javascript and HTML in chunks that you can easily reuse at the server side. JSP really only has jsp:include for templating, which is rather limiting.

Another small handy thing with JSF is that you have easy programmatic access to the request and response objects corresponding with the current request. If you're not taking advantage of many of JSF's core features, then in JSP/Servlet style programming this can be a small advantage.

But as BalusC already indicated, maybe JSF is not for you. The greatest benefit is when using the framework for its components. If you don't plan on using these, some request based might fit you better.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
  • GET indeed became possible in v2.0 and in 1.x was an awful hack. There are several libraries out there for user input validation - it's not a "JSF thing" :) Similarly for converters! The only difference between the tempting you can do with plain JSP and JSF is that in the later case, it more closely resembles an XML syntax and in its early development was though that it could support WYSIWYG editor more effectively. Again there are many template engines to use with JSP if you want, e.g. Velocity. Finally accessing the request and response object is equally easy in servlets, JSPs, JSFs, etc. – Kay Pale Jan 12 '11 at 23:44
  • By default, in Servlets you have to pass those two objects around. Of course, you can build a Servlet filter that stores them in a TLS variable and then in a finally clause removes them again. No big deal. Just wanted to mention that in JSF this has already been done. It's a small thing (very small), but the question was what benefits JSF still had when not (really) using components. – Arjan Tijms Jan 14 '11 at 11:30
  • *Again there are many template engines to use with JSP if you want, e.g. Velocity* - But then you're not really using plain JSP. Then you're using Velocity, and the question should be JSF vs Velocity, right? In a way, JSF is also a templating engine (optionally) to be used with JSP... – Arjan Tijms Jan 14 '11 at 11:32