On Thu, Jun 18, 2009 at 7:46 AM, Carl-Eric Menzel <[email protected]> wrote: > Then you already have an object that your components can work on. Put > that in a Wicket model and enjoy. My point is this: You either have > existing business code that supports conversations - then you don't need > Wicket conversations, you need to write your components so they work > with the existing code's notion of a conversation.
Wicket needs to understand when it needs to resume a previously-begun conversation. The business logic can't know that by itself. The UI has to provide a bit of help. > > Or you don't have a "business" conversation, and the whole conversation > thing is just something for UI workflow. Then you should not have it in > the business code. Instead, write components and models so that they > keep all the state they need for this "conversation" where they need > it. I don't think there needs to be a special abstraction for this, > you'd be much better off with keeping state as appropriate for your use > case. The idea of a "conversation" has been around for a long time. It's called a stateful session bean. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
