Re: [shale] subview not talking to a backing bean
Thanks for the response. The header.jsp does indeed have the page directive at the top. %@ page contentType=text/html;charset=UTF-8 language=java % %@ include file=include.jsp % the include.jsp has the taglib includes in it. There are other items in the header.jsp that are using the JSF-EL to access attributes in the session that are rendering fine, so I know the JSP is getting rendered as a jsp. h. for your other suggestion, using the include directive would may not work for me as the header file is included by other jsps that are in different levels of directories. I had chossen to do the jsp:include over the directive, because of previous relative urls in the header, that are now gone. I'll give it a shot - but I'd prefer to figure out why the jsp:include isn't working as expected. I think my issue is that the backing bean isn't getting instantiated on the request for the subview. Is there some rule about how subviews can't talk to different backing beans? Perhaps Shale is doing something to the request? Any further ideas? Jason On 1/31/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Jason Vincent [EMAIL PROTECTED] Hey there, I have a header.jsp file that is included in all my jsps: or if the including jsp was in a subdirectory... inside the header.jsp I'm trying to call a request scope backing bean to call a method to dynamically build some javascript. Here is my managed bean definition: header com.prenet.cpt.presentation.Header request The problem is that the header.isAdmin() method is not being called. And futhermore the default constructor for the Header.java class isn't being called. the Header class is not a ViewController as it doesn't match the url-to-bean mapping for whatever page I'm on. What could be going on here? Is there something speacial that has to be done in a subview? It doesn't sound like the target page is defined as a JSP page. Since you are using a jsp include, the target page needs to have the jsp page directive at the top of the file. If you are using the older style it would look like this: [EMAIL PROTECTED] contentType=text/html;charset=UTF-8% %@ taglib prefix=f uri=http://java.sun.com/jsf/core; % %@ taglib prefix=h uri=http://java.sun.com/jsf/html; % %@ taglib prefix=s uri=http://struts.apache.org/shale/core; % You could try using the include directive which will merge the pages into one unit. [EMAIL PROTECTED] file=header.jsp% Thanks, Jason Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] subview not talking to a backing bean
From: Jason Vincent [EMAIL PROTECTED] Thanks for the response. The header.jsp does indeed have the page directive at the top. the include.jsp has the taglib includes in it. There are other items in the header.jsp that are using the JSF-EL to access attributes in the session that are rendering fine, so I know the JSP is getting rendered as a jsp. h. for your other suggestion, using the include directive would may not work for me as the header file is included by other jsps that are in different levels of directories. I had chossen to do the jsp:include over the directive, because of previous relative urls in the header, that are now gone. I'll give it a shot - but I'd prefer to figure out why the jsp:include isn't working as expected. Oh, I didn't know what level you were on. I was hoping it was something simple. I think my issue is that the backing bean isn't getting instantiated on the request for the subview. Is there some rule about how subviews can't talk to different backing beans? Perhaps Shale is doing something to the request? There is no restriction on the number of backing beans for a view/subview. I don't think that Shale has anything to do with this issue and I suspect that if you removed Shale you would still have the same issue. You should be seeing an exception if JSF can't find the managed bean. That's why I asked about the quality of the JSP you are dynamically including. Is here a parent JSP tag that is not visible, rendered=false? If a parent tag is not visible, the children will not be renderered and your callback won't be invoked. Gary Any further ideas? Jason
Re: [shale] subview not talking to a backing bean
Again... thanks for the quick replies... I found a fix to my problem. Apparently header is a reserved word and cannot be used as the name of the managed bean. Originally this was my bean definition: managed-bean managed-bean-nameheader/managed-bean-name managed-bean-classcom.prenet.cpt.presentation.Header/managed-bean-class managed-bean-scoperequest/managed-bean-scope /managed-bean When I renamed it to header123... managed-bean managed-bean-nameheader123/managed-bean-name managed-bean-classcom.prenet.cpt.presentation.Header/managed-bean-class managed-bean-scoperequest/managed-bean-scope /managed-bean Things all started working. Sheesh! I wish JSF would have complained more loudly about the misconfiguration. Thanks, Jason On 2/1/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Jason Vincent [EMAIL PROTECTED] Thanks for the response. The header.jsp does indeed have the page directive at the top. the include.jsp has the taglib includes in it. There are other items in the header.jsp that are using the JSF-EL to access attributes in the session that are rendering fine, so I know the JSP is getting rendered as a jsp. h. for your other suggestion, using the include directive would may not work for me as the header file is included by other jsps that are in different levels of directories. I had chossen to do the jsp:include over the directive, because of previous relative urls in the header, that are now gone. I'll give it a shot - but I'd prefer to figure out why the jsp:include isn't working as expected. Oh, I didn't know what level you were on. I was hoping it was something simple. I think my issue is that the backing bean isn't getting instantiated on the request for the subview. Is there some rule about how subviews can't talk to different backing beans? Perhaps Shale is doing something to the request? There is no restriction on the number of backing beans for a view/subview. I don't think that Shale has anything to do with this issue and I suspect that if you removed Shale you would still have the same issue. You should be seeing an exception if JSF can't find the managed bean. That's why I asked about the quality of the JSP you are dynamically including. Is here a parent JSP tag that is not visible, rendered=false? If a parent tag is not visible, the children will not be renderered and your callback won't be invoked. Gary Any further ideas? Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] subview not talking to a backing bean
From: Jason Vincent [EMAIL PROTECTED] Again... thanks for the quick replies... I found a fix to my problem. Apparently header is a reserved word and cannot be used as the name of the managed bean. Gosh, that's one to remember :-) Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] subview not talking to a backing bean
On 2/1/06, Jason Vincent [EMAIL PROTECTED] wrote: Again... thanks for the quick replies... I found a fix to my problem. Apparently header is a reserved word and cannot be used as the name of the managed bean. Originally this was my bean definition: managed-bean managed-bean-nameheader/managed-bean-name managed-bean-classcom.prenet.cpt.presentation.Header /managed-bean-class managed-bean-scoperequest/managed-bean-scope /managed-bean When I renamed it to header123... managed-bean managed-bean-nameheader123/managed-bean-name managed-bean-classcom.prenet.cpt.presentation.Header /managed-bean-class managed-bean-scoperequest/managed-bean-scope /managed-bean Things all started working. Sheesh! Yah, that one is definitely non-obvious :-). For the record, there is a whole set of reserved managed bean names, which correspond to the magic beans JSF knows about. In turn, these correspond to the magic names in JSTL and JSP 2.0 expressions as well. The entire list (from JSF spec, section 5.3.1.2): * applicationMap - Map of application scope attributes (read/write) * cookie - Map of included cookies * facesContext - The FacesContext instance for the current request * header - Map of HTTP headers (includes only first for each header name if there is more than one) * headerValues - Map of HTTP header name to String array containing all the included values * initParam - Map of context initialization parameters * param - Map of request parameters (includes only the first for each parameter name if there is more than one) * paramValues - Map of request parameter name to String array containing all of the values * requestScope - Map of request scope attributes (read/write) * sessionScope - Map of session scope attributes (read/write) * view - The UIViewRoot of the current view I wish JSF would have complained more loudly about the misconfiguration. +1 for the general sentiment. Thanks, Jason Craig On 2/1/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Jason Vincent [EMAIL PROTECTED] Thanks for the response. The header.jsp does indeed have the page directive at the top. the include.jsp has the taglib includes in it. There are other items in the header.jsp that are using the JSF-EL to access attributes in the session that are rendering fine, so I know the JSP is getting rendered as a jsp. h. for your other suggestion, using the include directive would may not work for me as the header file is included by other jsps that are in different levels of directories. I had chossen to do the jsp:include over the directive, because of previous relative urls in the header, that are now gone. I'll give it a shot - but I'd prefer to figure out why the jsp:include isn't working as expected. Oh, I didn't know what level you were on. I was hoping it was something simple. I think my issue is that the backing bean isn't getting instantiated on the request for the subview. Is there some rule about how subviews can't talk to different backing beans? Perhaps Shale is doing something to the request? There is no restriction on the number of backing beans for a view/subview. I don't think that Shale has anything to do with this issue and I suspect that if you removed Shale you would still have the same issue. You should be seeing an exception if JSF can't find the managed bean. That's why I asked about the quality of the JSP you are dynamically including. Is here a parent JSP tag that is not visible, rendered=false? If a parent tag is not visible, the children will not be renderered and your callback won't be invoked. Gary Any further ideas? Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[shale] subview not talking to a backing bean
Hey there,
I have a header.jsp file that is included in all my jsps:
f:subview id=header_include
jsp:include page=header.jsp/
/f:subview
or if the including jsp was in a subdirectory...
f:subview id=header_include
jsp:include page=../header.jsp/
/f:subview
inside the header.jsp I'm trying to call a request scope backing bean
to call a method to dynamically build some javascript.
script type=text/javascript
h:outputText rendered=#{header.admin}
var showAdmin = true;
/h:outputText
/script
Here is my managed bean definition:
managed-bean
managed-bean-nameheader/managed-bean-name
managed-bean-classcom.prenet.cpt.presentation.Header/managed-bean-class
managed-bean-scoperequest/managed-bean-scope
/managed-bean
The problem is that the header.isAdmin() method is not being called.
And futhermore the default constructor for the Header.java class isn't
being called.the Header class is not a ViewController as it
doesn't match the url-to-bean mapping for whatever page I'm on.
What could be going on here? Is there something speacial that has to
be done in a subview?
Thanks,
Jason
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] subview not talking to a backing bean
From: Jason Vincent [EMAIL PROTECTED] Hey there, I have a header.jsp file that is included in all my jsps: or if the including jsp was in a subdirectory... inside the header.jsp I'm trying to call a request scope backing bean to call a method to dynamically build some javascript. Here is my managed bean definition: header com.prenet.cpt.presentation.Header request The problem is that the header.isAdmin() method is not being called. And futhermore the default constructor for the Header.java class isn't being called. the Header class is not a ViewController as it doesn't match the url-to-bean mapping for whatever page I'm on. What could be going on here? Is there something speacial that has to be done in a subview? It doesn't sound like the target page is defined as a JSP page. Since you are using a jsp include, the target page needs to have the jsp page directive at the top of the file. If you are using the older style it would look like this: [EMAIL PROTECTED] contentType=text/html;charset=UTF-8% %@ taglib prefix=f uri=http://java.sun.com/jsf/core; % %@ taglib prefix=h uri=http://java.sun.com/jsf/html; % %@ taglib prefix=s uri=http://struts.apache.org/shale/core; % You could try using the include directive which will merge the pages into one unit. [EMAIL PROTECTED] file=header.jsp% Thanks, Jason Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
