I was going to propose x:saveState, but x:inputHidden and forceId is
of course working as well!
Both are MyFaces extensions, by the way!
regards,
Martin
On 6/14/05, Richard Wallace <[EMAIL PROTECTED]> wrote:
> Richard Wallace wrote:
>
> > Richard Wallace wrote:
> >
> >> Hello,
> >>
> >> I'm having another problem with my select list and the value changed
> >> event listener. I have the following tag:
> >>
> >> <h:selectManyListbox id="organizations"
> >> value="#{contactHandler.selectedOrganizations}"
> >> valueChangeListener="#{contactHandler.handleOrganizationChanged}"
> >> onchange="submit()" immediate="true">
> >>
> >> This is for an "Edit Contact" page so when the page is initially
> >> loaded there is an organization selected. The problem that I'm
> >> having is that when I click the update button to invoke the
> >> appropriate action handler it is never called. The page just
> >> reloads. If I click the update button a second time it does call the
> >> action handler.
> >>
> >> I did a trace of the phases with a PhaseListener and found that it is
> >> jumping from the apply request values phase to the render response
> >> phase. So I added some logging in the places I call the
> >> FacesContext.renderReponse() method and lo and behold the
> >> handleOrganizationChanged() event handler is being called in spite of
> >> nothing on the page having been changed. To investigate further I
> >> logged the events old value and the new value and found that the old
> >> value was empty when it shouldn't have been.
> >>
> >> Is this a side effect of the event handling being declared as being
> >> immediate? What can I do to fix this?
> >
> >
> > Ok, I found the problem and it's entirely my fault. But it brings up
> > another question. Basically all my page backing beans are request
> > scoped and this is an edit page so I need to pass in the id of the
> > contact to edit. I did this in the getContact() accessor method which
> > checks if the contact is null and if it is gets the contact id from
> > the external context parameter map. This is all well and good when I
> > initially go into the edit page with the url
> > http://localhost:8080/contact/edit.jsf?contactId=11.
> >
> > In the form I try and carry this through with a hidden form element
> > called contactId thinking that I should still be able to lookup the
> > external context parameter value for "contactId" and get the right
> > thing. That is, of course, wrong because the actual form element name
> > is like "_id1:contactId". So the reason it comes up with the empty
> > list of selected organizations is because it's using a newly
> > constructed object and not one loaded from the backend.
> >
> > So now my question is what is the best way to carry the id across page
> > reloads like this? I've seen the method where you would have the
> > currentContactId be a JSF managed bean property and then pass in
> > param.contactId. But that runs into the same kind of problem. The
> > other method I've seen for doing this sort of thing is to make the
> > actual link the user clicks on to get to the page a <h:commandLink>
> > element bound to an option that sets the current contact in a session
> > scoped backing bean and then does a redirect to the actual edit page.
> > I don't like this for a number of reasons, one being the session
> > scoped backing bean and the other being that users can't bookmark the
> > URL. I'll have to discuss this with some people here to see if the
> > latter really is an issue or not, but I'd like to get the feedback of
> > people on the mailing list that have done this before. So, what's the
> > most commonly accepted practice on how to handle this? The session
> > scoped backing bean which wraps the actual data model object? Or is
> > there a better way?
>
> Well I found a couple of solutions to this problem. I'm not sure either
> is the best solution but they both seem to work well enough.
>
> One solution was to add <x:saveState
> value="#{contactHandler.selectedOrganizations}"> element. After doing
> some testing it seems this causes the selectedOrganizations property to
> be set in the restore values phase before even any immediate events are
> handled. So it seems like it might be a good rule of thumb to use
> <x:saveState> on any values that you need in the event handler.
>
> In this case, however, the better solution was to use a a myfaces
> extension and use <x:inputHidden id="contactId" forceId="true"> to make
> sure the element has the name that the backing bean uses to load the
> actual data object.
>
> Rich
>
>
>
