This content has been marked as final.
Show 3 replies
-
1. Re: Why does s:selectItems not work in this case?
swd847 Apr 21, 2009 6:35 AM (in response to dxxvi)Because page scope is evil.
Basically after you render the page for the first time the entityManager is closed and the entities in allLocations become detached.
When you submit the page the entityConverter calls find to get return the entity, which is a different instance to the object in the list (i.e. newObject != oldObject even though newObject.getId() == oldObject.getId()).
The selectOneListBox has a check in it to make sure that the object returned by a converter is equal (using .equals) to an object in the item list, as they are not it fails.
If you override .equals to compare based on primary key then this should start working, however do not do this without reading the article on the hibernate site about the pitfalls of doing this (once hibernate.org comes back up).
You could also implement a custom converter that specifically returns an item from the original list. -
2. Re: Why does s:selectItems not work in this case?
dxxvi Apr 21, 2009 7:06 AM (in response to dxxvi)Thank you very much for your explanation.
Could you tell me (or give me links) why page scope is evil?
Thanks again.
-
3. Re: Why does s:selectItems not work in this case?
swd847 Apr 21, 2009 7:42 AM (in response to dxxvi)It is not evil so much, you just have to be very very careful with it.
The most common problems that people have with it are due to entities becoming detached, like you were having here.
Also in client side state saving the page scope is serialized and sent to the client, meaning that you cannot trust anything in page scope if you are using client side state saving.
Also the page scope has no well defined life cycle.
I have found that a good rule of thumb is not to use the page scope for anything that cannot be considered UI specific logic.