It would be easier, and more the Wicket way - not to change your components, but to acchieve the same through the way you use models. Changing the component hierarchy in your page should not happen that often, as that would usually be done with a new page (e.g. editing an address instead of a customer).
So, in the case you are on an address edit page, and the actual address changes, just either replace the model on the component, or make use of the 'pull' nature of model. Someone on this list said last week that IModel is a bit misleading. IModel isn't a static holder of data you should replace when that data changes, or you want to use other data, but it is more of a resolver to get the actual model object. I think it is a good idea to check out the cdapp example, as this shows how the same page is used for editing a new CD, and updating an existing one. Currently, the only way to get it is from CVS. The project is hosted at: https://sourceforge.net/projects/wicket-stuff/ . It is part of wicket-contrib-examples. Eelco On 9/1/05, Doug Van Horn <[EMAIL PROTECTED]> wrote: > I'm getting started building an application using Wicket. I have a > pretty solid understanding of developing an app using Struts, but I've > never approached an app from this 'component' perspective before. I'm > just going to jump right in: > > I have this Model: Customer has a Set of Addresses > > I have an EditCustomerPage. On this page I provide a form for > changing the properties on the customer. I also provide a form for an > Address. Last, I provide a list of Addresses currently belonging to > the customer. > > This page is constructed one of two ways. First, you can construct > with a Customer object, indicating which customer you wish to edit. > Second, you can construct with a Customer object and an Address > object, indicating that you wish to edit a specific Customer and > Address. > > Upon your first arrival on this page, you will see an empty Address > form. For each Address listed I provide an Edit link. This link sets > the response page to a new EditCustomerPage, supplying a Customer and > an Address on construction. This leads me to a question: > > When staying on the same page, but changing some of the underlying > components (e.g., replacing a form backed by an empty Address to a > form backed by an existing Address), should I construct a new Page or > should I manipulate the current Page (e.g., by changing the Model on > the AddressForm)? > > Constructing the new Page is easy. But, is that the intent of the framework? > > I do the same thing once an Address is updated or deleted. I set the > response to a new EditCustomerPage. This causes my AddressList to > pull the fresh list of addresses from the Customer. If I didn't do > this, I'd need to somehow force the existing AddressList on the > current page to reflect the changed Address objects. > > > If anyone has an opinion on the subject, I'd love to hear it. As this > is all new territory to me, I have some learning to do... > > > Regards, > > Doug > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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
