On 8/23/05, Anders Peterson <[EMAIL PROTECTED]> wrote: > Juergen Donnerstag wrote: > > > I'm not very fond of replacing the model object, but I guess sometimes > > it is the only or the better choice. > > What do you normally do? Having a panel that, in the same page, should > display different things depending on what the user does must be a > common design pattern. >
create different panels and enable/disable them. > I do not know your application, > > but I guess I would go for a single model which contains all form > > component, whether set visible or not. And on submit propagate the > > information into proper businsess object if applicable. But of course > > that is only a suggestion and there are possible more approaches to > > it. > > Why not have the business object itself in the CompoundPropertyModel? > CompoundPropertyModel is fine and meets many requirements, but sometimes one of the other model is the better choice. There no single "this cover 100% of all requirements". Juergen ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
