Re: Recommendations for a web application framework?

Alan Meyer <ameyer2@xxxxxxxxx> wrote:
Do you or Chris think that using JSF is better than using, say,
Webwork or Spring? Or perhaps that it's just another approach?

I definitely feel that JSF is a better idea than Spring-MVC. I don't
know much about WebWork, but I'm pretty skeptical of new revolutionary
web application frameworks these days. One huge advantage of JSF (in my
view) that applies versus most anything else is that it is the standard
framework for web application development with Java. As such, I would
need a pretty good reason to switch away from it. I haven't seen
anything else that really is such a good reason.

JSF does an excellent job of separation of concerns. Although this has
been a major motivating goal of pretty much all major web application
frameworks, all of them that I've seen have fallen short until JSF came
around. With JSF, I can actually build my entire Java code without
having to think about the view layer at all; and I can build the view
layer while only worrying about the specific set of documented
properties and methods of backing beans. In almost everything else, you
have to do this naming convention junk between "form beans" and HTML
forms, and the form beans are not really all that abstracted from basic
HTTP parameter handling. With JSF, all that logic goes into the view
layer, whether it's JSPs or component implementations, and properly
converted and meaningful data is injected into backing beans from the
view, which the application can then handle from appropriate event
handlers. That's a HUGE advantage. Perhaps it sounds a tad trivial,
but it eliminates the biggest pains of real-world application
development when you no longer have to maintain simultaneous naming
conventions between Java code and JSP pages.

In your use of JSF, have you ever felt that it forbids you from doing
something that you really think you should do?

There are three major disadvantages to JSF:

a) It is a bit too intrusive on the view layer. While views can be
developed separately from application logic, they do need to be
developed using JSF components instead of HTML tags. This means that if
your model has been to have your graphic design department build HTML
pages and then go make the minimal changes to incorporate them into the
application, you'll have to change that a bit. Tapestry does a better
job of being unobtrusive, but at the cost of complexity elsewhere.

b) It limits your potential technology support and your use of the full
range of HTTP features. The two biggest limitations are that JSF
currently doesn't work at all with GET-style HTTP requests (unless this
has changed in 1.2), and that the JSP component bindings pretty well
require that the client have JavaScript enabled.

c) The Java APIs are rather weak in abstraction. The implementation
details of the container show through in a lot of places. This is
unnecessary, and makes JSF code appear messy sometimes.

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
.

Relevant Pages

  • Re: Learning JEE
    ... "workflow-level" BL in the JSF managed beans. ... presentation layer ... The action method ultimately wraps business logic (either by containing ... it, or calling session EJBs, or whatever), but in the workflow sense you ...
    (comp.lang.java.programmer)
  • Re: Model-Ebene bei JSF?!
    ... JSF stellt ja lediglich die View-Komponente der Gesamt-Applikation dar. ... Im Artikel "JSF for nonbelievers: ... mapping backing beans mediate between ... alternative is to delegate business logic to the application model. ...
    (de.comp.lang.java)
  • Re: Accessing columns of table - Java server pages
    ... Evrim wrote: ... In this case, I should have a java code that builds query string based on a loop that goes through the 2-D array, correct? ... JSTL and JSF to the rescue, specifically, EL. ...
    (comp.lang.java.programmer)