ManagedBean property not getting retrieved in JSP

[Ayan Biswas]

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

<tr:selectOneChoice label="Concern Type:" showRequired="true" id="concernType" unselectedLabel="Please Select" value="#{concernBean.concern.concernType.concernTypeCode}" disabled="#{concernBean.disableConcern}" autoSubmit="true" valueChangeListener="#{concernBean.checkValidRole}">
								<f:selectItems value="#{concernBean.concernType}"/>
								</tr:selectOneChoice>
								<c:if test="${concernBean.showAlert==true}">
								<script>
								alert("Only Global Account Manager can add group concern ");
								document.getElementById("save").disabled=true;
								</script>
								</c:if>
								<c:if test="${concernBean.showAlert==false}">
								<script>
								document.getElementById("save").disabled=false;
								</script>
								</c:if>

The checkValidRole method is like this :

public void checkValidRole(ValueChangeEvent e){
		logger.info("inside checkValidRole");
		LoginBean loginBean = (LoginBean) FacesContext.getCurrentInstance().
		getExternalContext().getSessionMap().get("loginBean");
		
		boolean flag =false;
		Iterator itr =loginBean.getRoleNames().iterator();
		while (itr.hasNext()){
			String roleName=(String)itr.next();
			if(e.getNewValue().toString().equalsIgnoreCase("GRP_CONCRN")|| e.getNewValue().toString().equalsIgnoreCase("COMP_CONCRN")){
				if(roleName.equalsIgnoreCase("Global Account Manager")){
					setShowAlert(false);
					flag =true;
					break;
				}
			}
		}
		if(!flag){
			setShowAlert(true);
		}
	
	}

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

document.getElementById("save").disabled=false;

The corresponding bean concernBean is registered as a session bean
What mistake am I doing here?

[Ayan Biswas]

Any idea on this issue?

[Tim Holloway]

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]

@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

<h:outputText  rendered="#{concernBean.validRole=='INVALID'}">
   								<script>
   								alert("You do not have the priviledge to perform this action");
   								document.getElementById("save").disabled=true;
					 			</script>
					 			</h:outputText>
					 			<h:outputText  rendered="#{concernBean.validRole=='VALID'}">
   								<script>
   								document.getElementById("save").disabled=false;
					 			</script>
					 			</h:outputText>

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

public void checkValidRole(ValueChangeEvent e){   
            LoginBean loginBean = (LoginBean) FacesContext.getCurrentInstance().   
        getExternalContext().getSessionMap().get("loginBean");   
           
        boolean flag =false;   
        Iterator itr =loginBean.getRoleNames().iterator();   
        while (itr.hasNext()){   
          /*some logic */
   validRole="VALID";
                }   
            }   
        }   
        if(!flag){   
            validRole="INVALID";
 
        }   
       
    }  

After doing this also it is not working.

[Tim Holloway]

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]

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]

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.