@Igor, this is really interesting. I can only imagine having a JPAConversational scope built around a Custom RequestCycle or is there could be other thing involved on this?
On Fri, Apr 15, 2011 at 11:58 AM, Igor Vaynberg-2 [via Apache Wicket] < [email protected]> wrote: > we use conversations a lot, mostly for keeping a jpa session open > across requests. > > imagine the following situation: > > you have a person entity that has a one to many relation to an address > entity and address has a many to one relationship with a city. you > have a page where the user can add multiple addresses to the person, > but the requirement is that none of the addresses are saved until the > user presses the save button. should the user add two addresses and > then press cancel none of the addresses are safe. this is a general > "atomic action across multiple requests" example. > > how do you do this with models? even if your entities are > serializable, which they probably should not be, you have a problem > with address->city linkage because it will become stale across > requests where each request has its own jpa session. so the easiest > but messiest way is to reserve to using some sort of dto to keep track > of added addresses, remove addresses, edited addresses, etc. the big > problem with the dto is now your components have to work with a dto as > well. eg you have to support add(new AddressEditor("foo", address)) > and add(new AddressEditor("foo", addressDto));, and no - they cant > implement some interface unless the address dto knows how to lazy load > city from jpa session,etc, etc. look how long it took just to describe > this. > > using a conversation workflows page or pages like this are *no > different* then others. we store our jpa session in conversation. when > the page loads we mark conversation as persistent so it will survive > across requests and is passed from page to page - unless user > navigates to a bookmarkable page. we also set the jpa session to flush > mode manual. all code works like it normally would, with entity > models. it doesnt know that it is working across requests. our entity > models are smart enough to know that until the entity has an database > id it should be stored in a special conversational store that is > basically a map:uuid->object. when the user presses save we flush the > session and all of their changes are persisted in a transaction. when > the user presses cancel we clear the session and close the converation > - which undoes all their changes. this has the added bonus of the > session acting as a database cache for the workflow. > > -igor > > > On Fri, Apr 15, 2011 at 12:45 AM, Carl-Eric Menzel > <[hidden > email]<http://user/SendEmail.jtp?type=node&node=3452263&i=0&by-user=t>> > wrote: > > > I have to admit I've never quite understood the need for seam-style > > conversations in Wicket. Whenever I need to do some kind of > > defined workflow, I simply use appropriate IModel instances that get > > passed around between the participating components. What is the use > > case of using a conversation construct over models? > > > > Carl-Eric > > www.wicketbuch.de > > > > On Thu, 14 Apr 2011 23:14:14 -0700 > > Igor Vaynberg <[hidden > > email]<http://user/SendEmail.jtp?type=node&node=3452263&i=1&by-user=t>> > wrote: > > > >> seam-wicket provides a full implementation. > >> > >> if you want "clean" you can build it yourself, its not too difficult. > >> subclass session and inside put a map of <conversationId,conversation> > >> and manage that map however you see fit in your app. > >> > >> -igor > >> > >> > >> On Thu, Apr 14, 2011 at 10:55 PM, YK <[hidden > >> email]<http://user/SendEmail.jtp?type=node&node=3452263&i=2&by-user=t>> > wrote: > >> > Are you planning to develop a conversation/workspace module ? > >> > > >> > What I mean by "conversation" is a "session portion" or > >> > manageable/controllable "mini" session > >> > that can be started and finished programmatically. > >> > > >> > This allows building multi-step programs and/or workflow and permits > >> > generally memory (objects in session) management. > >> > > >> > I know that wicket-seam provides this (partially) but what I would > >> > like to know is : could we have a "pure" > >> > wicket one ? and if it is feasible. > >> > > >> > > >> > Thanks > >> > > >> > -- > >> > View this message in context: > >> > > http://apache-wicket.1842946.n4.nabble.com/wicket-conversation-workspace-tp3451294p3451294.html<http://apache-wicket.1842946.n4.nabble.com/wicket-conversation-workspace-tp3451294p3451294.html?by-user=t> > >> > Sent from the Forum for Wicket Core developers mailing list archive > >> > at Nabble.com. > >> > > > > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://apache-wicket.1842946.n4.nabble.com/wicket-conversation-workspace-tp3451294p3452263.html > To start a new topic under Apache Wicket, email > [email protected] > To unsubscribe from Apache Wicket, click > here<http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1842946&code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=>. > > -- Sincerely, JC (http://www.linkedin.com/in/jcgarciam) --Anyone who has never made a mistake has never tried anything new.-- -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-conversation-workspace-tp3451294p3453211.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
