Urbani, Edmund wrote > I don't think I am the only one running into these kinds of issues, so I'd > like > to hear which patterns other developers apply or what they consider best > practices.
Would like to hear the same. I've attempted to work through this in the most Wicket-way I know how. The approach so far is a kind of LoadableDetachableModel that tries to be smart about the persistent state of the underlying entity/object. A persistence provider (entitymanager or such) would be injected into the model or requested by the model, and a flag or flags used to track the state of the underlying entity - is the entity currently managed? is the entity to be retained (that is, not automatically detached)? is the entity currently attached? So at the start of a wizard, the model is given a new entity and told that it is un-managed and retained. As the model is passed to the next page or to a previous page, the entity is serialized (not detached) and treated as though it doesn't belong to a persistence context. At the end of the wizard the model is told to persist the entity at which time it becomes managed but not retained (so it detaches, and would be re-attached via persistence id lookup when the model is next deserialized/loaded). A wizard or other set of pages working with an existing entity that was selected from persistence just tells the model that it is managed and retained. Then the model still doesn't "detach" in the sense of setting the underlying entity to null, but it does "detach" from the JPA context and is safely(?) serialized. Thereby changes made in wizard pages ride along to the end as in the new entity case above, and aren't merged til whatever final page/part logic says so. Cancelling out in the middle is simple since no changed would have been persisted. It works for any generic entity in my projects so far, however my use case right now isn't complicated by multi-entity editing; only one entity (one model's underlying object) is being modified by a single form submission in the open-session-in-view cycle. If there are other drawbacks to this approach or a better way (a more Wicket-way)... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Dealing-with-transient-and-persistent-objects-in-Wicket-sessions-and-models-tp4671222p4671240.html Sent from the Users forum mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
