Korhonen, Kalle wrote:

Yeah, you are definitely doing something wrong. The problem in your case
is that you are using two different beans with different scopes. The
properties of the longer-than-request scoped bean are populated before
the action in your request scoped bean is executed, but you are likely
using the session scoped bean as a managed property of the request
scoped bean, and those instances are set when your request scoped bean
is created.


Ok I think I got it, what you want me to say is, that the request scoped bean is not generated at the time the properties are set the first time, it is generated after the action is executed and hence the param pusihng does not work within the action? Hence the parameters correctly are passed into the next form display
but the data table is rendered with the non existent first params.


a pattern like myobject.delegate.val creates the delegate object only if possible and if not nothing and ignores anything myobject related, before the action call and after the call the delegate.val is populated
at a second call to the object which now exists?
sounds weird to me, because myobject should already be initialized
at the first call and the delegate is assigned at construction time


and a pattern of myobject.val creates myobject and populates it if possible before the action call, sounds weird to me, but given that
you can do anything, it is possible. I am just wondering why the
designers of the specs specified this?



The whole thing causes it to look like the propery updates
are coming in "late". One way to fix it is to move your search action to
the same bean as where your search properties are, which is a better
design anyway.



Yes... due to the mixes scope I needed, and not knowing x:saveStage I ran into the conclusion I had to do the caching myself - hence the delegates within the backing bean (delegates are very convenient if you have to mix two objects with different scopes).

We have a similar page, but our search backing bean is request scoped,
and only the results are stored in the session scope with x:saveState.



I will look into this, if this works it will simplify things tremendously, because then I can dump lots of cache related things,
thanks for your help.




Reply via email to