On 9/1/05, Rick Reumann <[EMAIL PROTECTED]> wrote: > What's not working is when I get to the 'saveAction' method of my > backingBean the 'id' of the Employee object in my backingBean > (EmployeeAction) is null. I would think that if I did saveState on the > whole EmployeeAction class on the JSP that the id would be there in > the same Employee object that is able to output the id fine in a > hidden field.
I don't know all the answers. However, the managed beans are going to be recreated from scratch the first time they're referenced in the session. Then you're going to restoreState on top of them. Are you sure that you are restoring the data you think you're restoring? I'd recommend setting a breakpoint in the t:saveState component so you can examine the employeeAction and employeeAction.employee before and afterward to see if it's doing what you think it's doing. If it looks fine after the state has been restored, then something else might be resetting the id value. You could set a breakpoint on your setId method and see if you can find out what's doing it. > But what if I potentially wanted to prreserve a bunch of properties, > not just id? Wouldn't it make sense to saveState on the whole > backingBean? Sure. I wanted to make sure you knew that you didn't have to serialize the entire bean if all you needed was to save was the id, though. The more you serialize, the more space/bandwidth it requires.
