• Post Reply Bookmark Topic Watch Topic
  • New Topic

Dissecting JSF component and lifecycle phases  RSS feed

 
Akhilesh Trivedi
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have been two books on JSF but yet to digest this topic. I am just a plain core java developer with little knowledge of servlets and jsp... and with this, am heading towards JSF.

"Restore view creates a server-side component tree (View) in memory to represent the UI information from a client."

Said this one, what is meant by memory, the JVM on server? Is there any class by name "View"? How does UIComponent differ from UIViewRoot?
what is UIViewRoot?
how do we differentiate a client-side component and server-side component?
what is the mapping betweent the two? will it be ok if I say, the radio button on the browser is a client side component, the server however has its own radio(in swings) for its own calculation/processing?
how does HTMLSelectOneRadio differs from a JRadioButton in swings?
 
Tim Holloway
Bartender
Posts: 18715
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JSF is based on HTTP, so HTTP sets most of the limiting factors. HTTP assumes a fairly stupid client (I'm ignoring JavaScript/AJAX for the moment). So the client-side components are ultimately going to be one of the half-dozen or so HTML input controls. All the real work is done on the application server.

So yes, the tree is built in the server's JVM. To be precise, it's reconstructed from the ground up each time the client (web browser) submits another request. The JSF process runs, then updated HTML is sent back to the client and the tree is tossed to the garbage collector. Another request and the process repeats. And so forth.

I try very hard not to get involved in the inner workings of JSF, since they're the parts most likely to be troublesome. Unless I'm actually developing a custom JSF tag, for example, I prefer to consider the tree in terms of its logical functionality and not worry about what specific Java classes are being used to hold and manipulate it.

JSF does not use Swing at all. Swing is a client-machine GUI used for Applets (which JSF doesn't employ) and for standalone Java Applications. All the basic UI stuff in JSF is done using HTML.

Now that I've said that, in the real world, people are very frequently adding JavaScript functionality to their web pages to make the client smarter. There are some JSF custom tags that add JavaScript to the client's HTML for various useful purposes, such as the Tomahawk popup calendar control. I'm looking forward to the day when AJAX-enabled JSF tags will be plentiful and easy to use. However, JSF itself doesn't depend on this sort of thing. If a user disables the JavaScript and applet facilities in their browser, JSF apps can still function just find.
 
Gabriel Claramunt
Ranch Hand
Posts: 375
Monad Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like to add my 2 cents:
View is a reference to the Model-View-Controller (MVC) design pattern
In JSF (and almost all web presentation technologies), client is the web browser and server is the web server, and the web browser has very little functionality.
Totally agree with Tim in trying not to get into the internal details of JSF, counting the lifecycle as not internal :-)
BTW, Tim, have you looked at IceFaces? They have open source AJAX JSF components, and the demo looks very cool. Anyway I didn't used them in any project, I don't know the drawbacks, but I think JSF + AJAX is a great combination
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!