Very weird:
I did some more tests, and I found out if I have the values printed out *after* the </h:form> tag, they *are* rendered. (after being triggered by the same ValueChangeEvent from the menu in the form)
Could the setup of (schematic)

<h:form>
<h:selectOneMenu to pick a User and fire off a ValueChangeEvent) - The User's data are meant to be rendered inside the below table>
        <table>
                ... (non-JSF: pure HTML)
                <h:panelGrid>
                ...// user data are not rendered here after ValueChangeEvent:-(
                </h:panelGrid>

                ... (non-JSF: pure HTML)

                <h:panelGrid>
...// this other part of the user data *are* rendered after ValueChangeEvent (??!)
                </h:panelGrid>

         </table>
</h:form>

... perhaps be the cause of all trouble?

Philippe


On 22 Feb 2006, at 20:16, Philippe Lamote wrote:

Hi,
I've run into weird prob and as I don't see why this happens, I thought posting it: In a page, I have a Select Menu. This fires a ValueChangeEvent to retrieve User Data. So, the user selects a "Person" from the Menu, and this Person's data are subsequently rendered below this Menu.
The strange thing is:
Of all the inputText fields (like "currentUser.firstName"), none is rendered. (all of them are inside the panelGrid) However, the correct person is identified. I see that in the logging of the return value and : The user data inside "Menu Lists" (like the current Person's "userRolls" ) *are* correctly rendered.

--> ?? How come inputText values are not retrieved, and values in the Menu are??

This is the code:
(to select a certain user, which triggers the Event)
<h:selectOneMenu id="userChooser"
title="#{labels.usrMgt_userChooserHelp}" valueChangeListener="# {managerbean.chooseUserTrigger}" disabled="# {managerbean.usersdisabled }" onchange="submit()" value="choose_one" > <f:selectItem itemLabel="#{labels.usrMgt_chooseUsr}" itemValue="choose_one"/>
                <f:selectItems value="#{managerbean.userKeyMap}"/>
</h:selectOneMenu>
...

<td>
(the panel with textInputs that DON'T render the user data:)
<h:panelGrid bgcolor="SlateGrey" columns="2" id="userTabel1" cellpadding="2" align="center" columnClasses="labelKolom,inhoudKolom" rowClasses="even,oneven">
                        <h:outputLabel value="#{labels.usrMgt_firstn}"/>
<h:inputText value="#{managerbean.currentUser.firstName}" readonly="#{managerbean.editableFieldMode}"/>
...
                                                                
</h:panelGrid>
<h:message for="userTabel1" styleClass="error"/>
</td>


(& the panel with data that do get rendered with the user data:)
<h:selectOneMenu id="roleList" title="# {labels.usrMgt_roleListTitle}" value="#{managerbean.oldRollKey}" readonly="#{managerbean.editableFieldMode}" > <f:selectItem itemLabel="#{labels.usrMgt_usrRolls}" itemValue="choose_one"/>
                        <f:selectItems value="#{managerbean.userRolls}"/>
        </h:selectOneMenu>


The code for chooseUserTrigger, in the backing bean (managerbean) is
        
        public void chooseUserTrigger(ValueChangeEvent event){
                
                String gekozenUser= event.getNewValue().toString();
                logger.error("The Chosen User, is "+ gekozenUser);
                setCurrentUser(getAppMgr().getUsers().get(gekozenUser));
                
        }

Person currentUser is a local var of the backing bean, featuring vars like firstName (String, ... ), rolls (TreeMap),… nothing special there. Again, I see from the logging the correct user has been passed to the serverside, but only the data in the InputText fields doesn't seem to be retrieved.
Has anyone else had similar experiences?

(Ps The only -non relevant, just mentioning it anyway- difference I see, is that "firstName" etc is indirectly referenced, via the bean's local var "currentUser.firstName". Whereas for the rolls, in the bean, there is a method getUserRolls(), which is a mere pointer to this same local variable (in casu: it returns getCurrentUser ().getRollKeys(); ) This is not relevant and just to make sure it isn't, I did the same for firstName (i.e. make a dedicated bean method doing getCurrentUser.getFirstName(), but this had no effect...

Philippe


Reply via email to