• 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

ManagedBean property not getting retrieved in JSP

 
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have added a value chage listener in a JSP page in JSF 2.0 and in the method I have set a bean property like this

The checkValidRole method is like this :


I can see that inside the checkValidRole method when flag is false setShowAlert is getting set to true but in the JSP page the bean property is not getting retrieved properly.It is always showing false.I can see the follwing snippet when I do a view source of the page in the browser

The corresponding bean concernBean is registered as a session bean
What mistake am I doing here?
 
Ayan Biswas
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Any idea on this issue?
 
Saloon Keeper
Posts: 27763
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

Ayan Biswas wrote:Any idea on this issue?



Yes. Please don't "bump". If someone has an answer, they'll provide one. But since we do this for free, it may take a while for someone to get around to it. It's still early in the morning where I'm at.

You have a fundamental misunderstanding of JSF. JSF version 2 does not use JSPs. JSF2 pages are coded as View Definitions and stored (usually) in resources whose suffix is ".xhtml".

A JSP is something that the JSP compiler converts into a servlet and executes. A View Template is data. It is compiled by the FacesServlet into a View Component Tree data structure. Servlets are executable code. Data is not.

Which brings me to the next item. Despite some questionable examples from Oracle, JSP's JSTL and JSF are a bad mix. JSTL is designed to add logic support for the most part, and the View Definition shouldn't be including logic, since it's data. More to the point, JSTL never did work that well in JSF, even in JSF1 where the "View Templates" were still (usually) JSPs. Despite improvements, JSTL is still dangerous to use in JSF2. And there's no need to. JSF has equivalents to the JSTL tags that are more in harmony with the JSF approach to view layout and usually simpler to use than their JSTL counterparts.
 
Ayan Biswas
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Tim Holloway I apologize for being impatient.

Despite some questionable examples from Oracle, JSP's JSTL and JSF are a bad mix.


I have changed my code in the JSP page in the following way


In the method bound to ValueChangeListener I have done the necessary adjustments

After doing this also it is not working.
 
Tim Holloway
Saloon Keeper
Posts: 27763
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
Well, here are some more items.

A) You should not normally be using the Service Locator pattern to "get" the location of loginBean. JSF is about Inversion of Control, so the preferred way is that the loginBean is injected automatically into the bean you are working with without any user logic or reference to JSF-specific code and data objects.

B) If you are expecting the valueChangeEvent listener to be fired automatically when the user updates the GUI, that's not how that works, either. JSF is based on HTTP, HTTP doesn't connect-and-converse the way client/server does, but instead works with paired request/response messages, with requests being initiated by commandButtons, commandLinks or explicit entry of a URL in the user's browser navigation control. The valueChangeListener gets invoked ONLY if all of the submitted data is valid, and then only if the control that it is attached to has an actual change of value.

C) Javascript manipulation of the "rendered", "disabled", and certain other JSF control properties doesn't always work the way it would for basic HTML. Also, the control IDs used by JavaScript are not the same values as the "id=" attribute on the JSF control.
 
Ayan Biswas
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


B) If you are expecting the valueChangeEvent listener to be fired automatically when the user updates the GUI, that's not how that works, either. JSF is based on HTTP, HTTP doesn't connect-and-converse the way client/server does, but instead works with paired request/response messages, with requests being initiated by commandButtons, commandLinks or explicit entry of a URL in the user's browser navigation control. The valueChangeListener gets invoked ONLY if all of the submitted data is valid, and then only if the control that it is attached to has an actual change of value.


Sorry I did not get this point. I can see that the control in getting tranferred to the method bound to the ManagedBean when the value is chaged in GUI. The problem is that the bean property that is getting set in the method is not getting retrieved in the GUI
 
Tim Holloway
Saloon Keeper
Posts: 27763
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


JSF version 2 does not use JSPs. JSF2 pages are coded as View Definitions and stored (usually) in resources whose suffix is ".xhtml".



I repeat that because if you don't recognize the distinction, it will cause you endless trouble.

As I said before, HTTP requires an explicit submit. You are using a third-party tag set which can do the submit automatically (autoSubmit=true) on a value change. Most JSF tag sets don't support that, which is why I said what I did. I didn't notice the finer details until I looked closer.

Actually, while I'm not familiar with whatever extension package you are using, the "autoSubmit" is actually an AJAX submit. AJAX submits are different from the basic commandButton/commandLink submits in that they don't cause JSF to navigate to a new page. However, to cause the current page (or parts of it) to update showing updated backing bean values, you need to tell the package what parts of the page to update. That is usually done by a "reRender=" or "render=" attribute on the tag that does the AJAX submit. I would expect that there's something like that available for the "tr:selectOneChoice" control, but I'm not familiar with that particular tag so that's the limit of what I can say.
 
reply
    Bookmark Topic Watch Topic
  • New Topic