This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
As attached snapshots and sample program. We set value of a hidden field in the prerender method in the managed bean. Then we use javascript : document.getElementById() to get the value of that field. We can successfully get the value in netbeans 6.0 VWP beta 1, but failed to get the value in netbeans 6.0 VWP beta2. However, instead of setting that value in "prerender" method, we bind that hidden field to a value in design time. Both netbeans 6.0 VWP beta 1 & beta 2 can get the value by document.getElementById() Please don't close this issue before testing my sample program in Netbean 6.0 beta1 & beta 2 environment. Please find attached running result snapshot & my sample program.
Created attachment 51671 [details] Running result in netbeans 6.0 beta 1
Created attachment 51672 [details] Running result in netbeans 6.0 beta 2
Created attachment 51673 [details] Managed bean of my sample program
Created attachment 51674 [details] JSP file of my sample program
Wayne, first of all using the generated ID for Javascript processing is a not a good idea. JSF does not gauratee the correctnedd of the id. You need to be very careful and need to modify it yourself, since there is no guarantee that it will remain constant. Here is an example - Add a button component and use "form1:button1" in your javascript and everything will work fine. - After several weeks, you wanted to rearrange your components and used grid layout panel and moved the button inside it. - Now all of a sudden your javascript will start working because now the id is something like "form1:gridpanel1:button1" This is what I meant by there is no guarantee that the generated ID will be preserved. There is no point in filing a p1 bug against IDE, because IDE can not help you in this regard in any sense, since it is impossible for the IDE to guess what has been generated and what has been changed by the user in the javascript. I certainly agree to your concern. The best bet may be bring this up with the Woodstock team who provides the components for NB VW at https://woodstock.dev.java.net/index.html
Hi Wahu, If you go through the JSF request processing lifecycle as documented in JSF Spec, you will find that JSF framework internally maintains a tree of all the components in the page which plays a key role in state saving and rendering. This tree does not get created until the render response phase. So I wouldn't recommend set the "id" during pre render because it is not guaranteed to be preserved as this is managed by the JSF framework. This will get overridden during render response phase. Recommended way is to set the "id" in the JSP or you can use a phase listener to programatically create components and add it to the tree. As Winston said, you can file an issue with Woodstock project to confirm that is indeed the case. Thanks -Jayashri
winston, The fact that the behavior is different from beta 1 to beta 2 needs to be evaluated. It could be related to be the BodyRenderer changes that were checked in. But we need to make sure. I suggest you file a bug against woodstock and close this. thanks
After a little bit of research now I found out why the problem occurs. The problem is now the hidden field is now rendered with dojo client side rendering technique. If you look at the source using browser -> source view, for hidden field you would see <span id="form1:field"></span> and then the java script <script type="text/javascript"> 1dojo.addOnLoad(function() {webui.suntheme.widget.common.replaceElement("form1:field", {"widgetType":"webui.suntheme.widget.hiddenField","value":"test","disabled":false,"name":"form1:field","id":"form1:field"});webui.suntheme.bootstrap.body = new webui.suntheme.body('/Page1.jsp', '/TestApplication/faces/Page1.jsp',null,null,'com_sun_webui_util_FocusManager_focusElementId',true);}); </script> It appears, this javascript lazily replaces the <span> (id "form1:field") with <input>(id "form1:field"), the javascript executed after that gets screwed up. I'm moving this bug to woodstock to get a solution in such a scenario.
I have filed an issue against Woodstock Components. So closing this bug as will not fixed. Track the progress of this bug at https://woodstock.dev.java.net/issues/show_bug.cgi?id=873