Just had a look at the spec (i.e. javadoc) and the RI source code:
How we handled the List was absolutely correct IMO.
The problem you have, would also arise with the RI. So, I do not so a
reason to do this trick in the MyFaces implementation. The drawback
of your patch is: If someone has a List
Hello Manfred,
I think I get it now. Sorry for that.
But the x:saveState should still return the same object (value classes) as the given one.
So, the right solution would be to override the UISaveState.saveAttachedState to just serialize the given bean.
Do you agree with this solution ?
I think I get it now. Sorry for that.
But the x:saveState should still return the same object (value classes)
as the given one.
So, the right solution would be to override the
UISaveState.saveAttachedState to just serialize the given bean.
Do you agree with this solution ?
Yes,
One problem though :
UIComponentBase.saveAttachedState is static.
Do you think we can make it non-static to allow the overridden method to work ?
On Tue, 2005-08-09 at 14:35 +0200, Manfred Geiler wrote:
I think I get it now. Sorry for that.
But the x:saveState should still return the
No, no way to make it non-static because it's defined as static in the spec.
Hmm, no idea at the moment.
Isn't it a simple workaround, to wrap your special List into an
serializable managed bean?
-Manfred
2005/8/9, Sylvain Vieujot [EMAIL PROTECTED]:
One problem though :
Hello Manfred,
Here is a specific example where savestate would fail :
x:saveState value=#{myLinkedList}/
The save state would return a List, and not a LinkedList.
So if you use somewhere in your code myLinkedList.pool(), it would fail.
In fact it fails earlier, as the saved value can't be
