• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

nuances of JSF confusing

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello everyone,

For my web development class I was tasked with choosing a web technology, learning about it and coming up with a short presentation of it.

I decided to learn about Java Server Faces. I am fairly certain that I understand how they work, but some of the little nuances of the technology still confuse me.

One thing that I do not understand in particular is how the xhtml pages work. For instance, in a simple JSF application, I have an input for a first name and last name located in a xhtml file called userInput.xhtml. The user enters text into the two inputs and hits the submit button.

For the submit buttons action, I have it set to my response.xhtml file which contains the JSF tags that retrieve the first and last name fields from the managed bean.

So I type in my name and hit submit, and everything appears to be working fine. The page changes and says "Hello John Doe". However, I noticed that the URL still says that it is on the userInput.xhtml file.

I was curious if anyone could explain to me what is going on here?

Thanks in advance for the help.
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, William!

Let's see if I can help.

JSF is a template-oriented Model/View/Controller (MVC) framework where the Views are produced from static View Templates (more or less), Controllers are the FacesServlet and the logic inside the template tag definitions and Backing Beans are Models with a little non-MVC freight like change listeners and action methods in them. Unlike most MVC frameworks, you don't write Controller code yourself, although the NetBeans IDE apparently incorrectly generates backing bean names as Controllers.

The normal approach in J2EE is that when a URL comes in, it is matched against a set of URL patterns in the WEB-INF/web.xml file. If the pattern matches a servlet mapping, then the URL is routed to that servlet. If not, then the container bounces it down an internal chain that attempt to figure out what to do with it, and I could tell you more on that, but it doesn't matter here.

So if you set up web.xml to take URLs that end with ".jsf" and map them to the FacesServlet, then the FacesServlet is responsible for what happens next. As of JSF version 2 and later, the FacesServlet will strip down the core resource path  removing the "http://", servername/port and application context paths from the front and removing the ".jsf" from the end. It then tacks on ".xhtml" to this resource path so that something like http://saloon.javaranch.com/jsfapp/admin/usercontrol.jsf would reduce to a webapp resource pathname of "/admin/usercontrol.xhtml".

Having done that, the FacesServlet will then open this resource - which is the View Template - and compile it to produce a data structure in tree form - the Component Tree. This object is used both as the basis for rendering the page to the client and for processing incoming form data. So when the original URL request comes in, the Component Tree is built and the "render response" JSF phase uses it to produce the HTML returned to the client.

The Component Tree isn't simply discarded, however. It's compacted and saved. Depending on the web.xml file, it may actually be sent in whole or in part to the client or kept locally on the server. Which option you use depends on the amount of network resources you have versus server storage and whether you trust critical data to be sent off-server where it might get tampered with.

Now the page has been rendered as HTML on the client and your jsf <h:form> has been used to build an HTML (or xhtml) <FORM> element (HTML is case-insensitive, but convention is upper-case for HTML and lower-case tagnames for xhtml and XML). This FORM carries the usual input controls - the core HSF tagset has correspondences to the standard HTML form controls, but there is some extra freight that also gets rendered into the form.

That's because the REAL fun begins here. JSF uses a mechanism called "postback". Instead of sending forms and responses back and forth, JSF acts as though the same form was there all along and only the data has been transported (actually JSF was designed so that systems which work that way could do precisely that. HTML, alas, doesn't).

So the user enters data, submits the form and the JSF processor drags out the Component Tree that it previously saved. Form control data is validated, and if invalid the JSF lifecycle short-circuits. The Component Tree is used to render an updated version of the client HTML form with appropriate error messages and stuff and it's bounced back and forth from client to server until all fields are valid. That's an important aspect of JSF. You cannot process a form until all data in the form is valid. The backing bean(s) will only be updated when the data is valid and the action method (or its AJAX equivalent) will not be invoked until the backing bean(s) are updated.

OK. So the action method does its thing and indicates that JSF should navigate to a new View. The client's URL should change, right?

Well, as you have seen, no. Not right away, and that's because the URL isn't a resource locator as it is in most frameworks so much as it is a resource handle. The View name isn't determined from the URL once the workflow has begun, it's determined by the JSF workflow manager. The display is one step behind the actual process, but that doesn't matter because of that characteristic.

Of course, there are times when it's not desirable for that to be the case. You might have especially picky users/bosses. Or, more practically, you might be using the J2EE Container Managed Security System to control access to critical resources. CMS Security is based on checking the incoming URL against the web.xml security patterns, so you have potential security loopholes when the URL lags the requested action. For that, there's a special navigation property: "redirect". Use of the faces-redirect option will cause an extra internal request to be made causing the client's navigation control URL to match the resource path of the View being rendered. It's extra overhead, but sometimes it cannot be avoided.
 
William Vukasovic
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello there Mr. Holloway!

First off, thank you for the incredibly detailed post, I really appreciate you typing all that out for me.

Second, I think I am understanding it more now. I went ahead and took a couple of screenshots of the two simple JSF apps that I have been toying with in netbeans to ask some follow up questions.

Album link: http://imgur.com/a/Rp67H

Okay, so in pictures 1-3, based on what you said in your post, what is happening is the display is one step behind the actual process? So instead of seeing the student_response.xhtml, which is where the output tags are, it is showing student_form.xhtml?

Then in the other pictures, I am curious why when I start up the application, it does not show the index.xhtml page. Is this also because of the display lagging behind?

Finally, I included a picture of the bean itself in the last picture. First off, I am sure there is a much better way to do what I did, but I kind of just threw it together to test out.

I was also having a little trouble storing data in some of the beans fields. I would get an exception, saying that the value/field of the bean could not be reached. Was having a little trouble differing between the @Named and @ManagedBean notations, and was curious if it had anything to do with that?

Sorry for all of the questions, it has been a little tough for me to grasp every little intricacy of JSF, and I want to be prepared for the presentation I have to give for it.

Thanks again for all your help!
 
William Vukasovic
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also, would you be able to point me towards any JSF project samples or tutorials you may know of? I am trying to soak up as much knowledge on this topic as possible.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic