JavaServer Faces

[Luke Webber]

This might sound like a rant, but it's a serious question...

Is anybody really using this JavaServer Faces stuff? I've done a fair
bit of JSP using JavaBeans to support it, but I honestly cannot see what
the big deal is about JSF. The source looks ugly, and there are a load
of things happening in black boxes, plus a load of extra Java code
(custom code and JSF APIs and taglibs) hidden behind the scenes. And the
damned thing is round-tripping to the server all the time!

Am I missing something? Does the emperor really have no clothes?

I guess I'm a bit of a reactionary. I don't really even like taglibs
like Struts, because to my way of thinking, they render the code
unintelligible to all but the initiated. And I think JSF it ten times worse.

OTOH, I'm prepared to be convinced otherwise. Some of the menu-handling
samples and calendar controls that I've seen look pretty slick, and
would be difficult to do in JSP.

Anybody want to take a shot at converting me?

Thanks,
Luke

 

[Andrea Desole]

Anybody want to take a shot at converting me?

definitely not now.
I have been using JSF for some months, and I'm thinking about changing.
It's fairly buggy, and at the moment a bit limited. It doesn't even have
a file upload control; it's true that it's possible to make one, and I
think that myfaces has made one available, but the fact the
specification is missing it makes me think.
Since I had some problems with a form I even started to think that there
can be some flaws in the design, but it's something I have to look
better into. I'll have to take some time to look at the specs.
Still, the concept seems to be mostly well conceived, and well
structured. I don't think there is anything you can't do with a regular
JSP with JSTL, but JSF has an interesting way of doing it. And the small
problems I am seeing now can probably be solved easily.
I think it's fair to look at how JSF is going to do in the near future.
I am waiting for 1.2

 

[Ross Bamford]

-try to read the spec. careful, study the source code at the same time,
and things will be different

You'll find that, in fact, the 'Emperor' is a fat, balding sales rep with
bad breath.

 

[Tor Iver Wilhelmsen]

Is anybody really using this JavaServer Faces stuff? I've done a
fair bit of JSP using JavaBeans to support it, but I honestly cannot
see what the big deal is about JSF.

Event-driven configurable webapp navigation? Sounds useful to me.

The source looks ugly, and there are a load of things happening in
black boxes, plus a load of extra Java code (custom code and JSF
APIs and taglibs) hidden behind the scenes.

Yes, that's the nature of frameworks. Whether it's the AWT or Swing
event threads, the EJB life cycle manager - or the web application
framework.

And the damned thing is round-tripping to the server all the time!

Add some AJAX or other Javascript. Going to the server is the only way
to do server-side code. But if you start relying on client-side code
you are giving the "enemy" (any malicious user) a weapon.

I guess I'm a bit of a reactionary. I don't really even like taglibs
like Struts, because to my way of thinking, they render the code
unintelligible to all but the initiated. And I think JSF it ten
times worse.

Then stick to writing to the Servlet 1.0 spec (or even use
ServerSocket), doing everything explicitly. Write everything from the
ground up, it's the only way to be certain. Don't trust other people's
code. Your wheel will be rounder than the one those guys invented.

However, that kind of thinking is the reason we have a million web app
architectures and frameworks: WebObjects, WebMacro, Velocity...

 

[Chris Smith]

However, that kind of thinking is the reason we have a million web app
architectures and frameworks: WebObjects, WebMacro, Velocity...

.... JSF, ...

No, seriously, some of the reason that we have so many web app
frameworks is that new ideas keep popping up that either aren't accepted
or don't fit in existing frameworks. The same is going to be true of
JSF. There are going to be things that it does well, and things that it
does poorly. If the first category outnumbers the second by enough of a
margin to justify retraining, then a new framework becomes successful.
That's all there is to it.

Let's not deny that there are very legitimate complaints about JSF. In
my book, the biggest is an utter lack of abstraction. Even the easy
stuff is botched. Methods are consistently named from an implementation
standpoint instead of an app development standpoint. Obvious
convenience methods are missing in FacesContext, forcing the user to dig
into irrelevant details to perform simple tasks. There are glaring
incongruences between JSF and JSTL and JSP-EL that require knowledge of
implementation details to use the technologies together.

Nevertheless, it's (IMO) silly to dismiss JSF's utility. It already
solves a lot of problems. Just a little bit of stronger abstractions
and an expansion of the standard component set will start making it look
very attractive. On top of that, a compelling strategy for handling
asynchronous interactions with the server would make it start to look
groundbreaking. With some better validation handling, ... well maybe
you see where this is going.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Roedy Green]

Yes, that's the nature of frameworks. Whether it's the AWT or Swing
event threads, the EJB life cycle manager - or the web application
framework.

Black boxes do amazing tricks when juggled by their authors. But in
that context they are not really BLACK boxes. Even if the application
code makes no use at all of unpublished behaviour of the interface,
the authors know how the boxes were intended to be used, what will
work, and what won't because they understand the internal model so
well.

That lore is nearly always lacking in the documentation. You need
reams of examples to convey it.

I find having a rough idea of the internal model, even a slightly
incorrectly one greatly helps figure out how to use black boxes. So I
think it is perfectly legit to peek inside to see how they work to
help sharpen your intuition on how to use the public interface.

Failing that I construct a mental internal model, and gradually refine
it as I learn more about the package. It is ever so much easier to
remember than all the fine detail you can often easily deduce as
needed from the internal model.

 

[Roedy Green]

... JSF, ...

Here is a tiny advertisement for reinventing the wheel.

Many years ago I was faced with the problem of how a large utility
could convert huge amounts of code from one platform to another.

It occurred that a utility of that size could probably afford to
create its own meta programming dialects with application specific
extensions specially for them, and translate it to various platforms.
This would include the scripting JCL languages. That would keep
hard-to-translate platform-lock-in features out of the codebase and
give them maximum flexibility in selecting new incompatible hardware.

Then they would never be at the mercy of a particular platform, or
language, or package. It sounds like a very expensive proposition,
but you have to offset that against the cost of conversions.

The idea is less viable now as coding has become more complex.

The other advantage which will never be appreciated until you have
actually done it is when ALL the code is yours, you can always find
bugs rapidly, and further there simply aren't any.if you build
carefully. So many bugs are actually caused by hooking together
software written by authors who have never met.

The hidden costs of using somebody else's class library include:

1. they can change the price at any time, especially run time
licensing.

2. they can drop the product.

3. they can refuse to fix bugs.

4. you can't fix bugs without source.

5. bugs in your apps are harder to track without source to the
library.

6. you never truly know how the package works without source.

The hidden cost of using your own library include:

1. there are fewer eyes looking bugs. It is up to you to find them
all, more likely in production.

2. there are more minds thinking of ways to improve the product.

3. the product will be more flexible. It won't be designed just for
one application unable to handle extensions easily.

4. It always takes much longer than you think to write, debug and
maintain a library. The cost of creating somebody else's code is
shared over all their customers.

5. somebody writing code for the market is likely to have a bigger
time budget to research the latest algorithms.

 

[writeOnceDebugEverywhere()]

This might sound like a rant, but it's a serious question...

Is anybody really using this JavaServer Faces stuff? I've done a fair
bit of JSP using JavaBeans to support it, but I honestly cannot see what
the big deal is about JSF. The source looks ugly, and there are a load
of things happening in black boxes, plus a load of extra Java code
(custom code and JSF APIs and taglibs) hidden behind the scenes. And the
damned thing is round-tripping to the server all the time!

Am I missing something? Does the emperor really have no clothes?

-try to read the spec. careful, study the source code at the same time,
and things will be different

 

[Roedy Green]

6. you never truly know how the package works without source.

Usually the author will not talk to you. If he works for you, or if
he is you, he will.

 

[Chad]

In my experience, JSF adds a lot of overhead which equals much slower
response times. We have put it side-by-side to plain old JSP's doing
extremely simple tasks and it is 60 to 500 times slower in most cases.
It looks cool but we have not been able to get it to hold up under
extremely heavy loads. I am still hoping to be converted as well but
that has not happened yet.

 

[hiwa]

I've been thinking that the main attraction of JSF
is that it is a blanket abstraction of the Web
dynamicity. Amy Fowler's forcible idea a la
Swing event model.

What kind of abstraction do you want to be added
to the future JSF spec or implementation?