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
<[email protected]> 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 <[email protected]> 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 <[email protected]> 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
>> > Sent from the Forum for Wicket Core developers mailing list archive
>> > at Nabble.com.
>> >
>
>
