On Thu, 18 Jun 2009 08:10:33 -0400 James Carman <[email protected]> wrote:
> 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. Yes of course. That's what I meant by "write your components so they work with your existing code". > The idea of a "conversation" has been around for a long time. It's > called a stateful session bean. You have a point there. But I think this is all provided by Wicket already - You have components and models that perfectly encapsulate all this. Basically this is about the lifecycle of the data needed for a unit of work from the user's point of view. If you have a flow of pages, or wizard steps, or whatever, you have a defined starting point where you can, for example, create a model. And then you go to the next step and pass this model along. Once you're finished, you just drop the references. Or am I missing something here? Carl-Eric --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
