If you're adding stuff to lists, you can build up a detached list as you go along (which gets stored in the session) and when you do the final submit to save the main object to the database, you grab the lists and stick them in there before you save it.
On Sat, Nov 21, 2009 at 7:34 AM, Bert <[email protected]> wrote: > Hi list, > > i 'm starting a new project with Wicket 1.4, JPA (Hibernate) and > Spring. So far, building > the web pages have been fun (panels, ajax,..) thanks to wicket. > > My problems arise when i use my UI Model (an IModel implementation following > Igors 'smart entity model' or one of the similar found in post like > [1]). To my understanding, > these are basically read only models, as all changes to them are > discarded in the detach() > and the model is freshly loaded from the db with the next request. > > [1] > http://stronglytypedblog.blogspot.com/2009/03/wicket-patterns-and-pitfalls-1.html > > Now, some forms span several requests (user adding stuff to lists and > such) and the LDM > approach is not working. > > What are my options here? I looked around at some open source project > using wicket and > they either do not use LDMs but set the persistent objects into the > components or use some > sort of DTO. > > I don't want to go that DTO way, it looks overly complicated and > involves lots of code that > does little in terms of application. Or is there a 'generic' DTO ? > > To my understanding, using the persistent objects directly in the > components would cause the entire > object graph being serialized into the session? > > In [2] Stefan Fußenegger suggest writing an serialization > implementation that either detaches > an object (when it is attached (in a hibernate sense) or serialize it > if it is transient. (thats how i > understood his post) > > [2] > http://techblog.molindo.at/2009/03/detaching-and-attaching-persistent-objects-on-serialization.html > > I feel like missing the obvious here, how do others handle this with wicket? > > looking forward to your answers. > Bert > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
