Chaps. Sorry, this is rather long. I am struggling to find a way to handle complex state in my application which will keep the session reasonably small.
Here is what I am doing: A Portfolio has many Position. class Portfolio { List<Position> getPositions(){... } I have a PortfolioPage which shows all Positions for a Portfolio in a reusable Panel: class PortfolioPage extends WebPage { public PortfolioPage(String ptfId ) { add( new PortfolioPane("XX", new PortfolioModel(ptfID)) ); } } class PortfolioPanel extends Panel { public PortfolioPane(String id, PortfolioModel model ) { super(id, model); RepeatingView v = new RepeatingView(); add(v); for( Portfolio ptf : getModelObject().getPositions() ) { v.add( new PositionRow(ptf) ); } } PortfolioModel is a LoadableDetachableModel and can quickly fetch its state (and all its Positions) from the DB using the ptfID. This is good. PositionRow is a Pane subclass which renders a single html row showing the Position information, so the RepeatingView will display a table of Positions. Now, as I understand it, Wicket will push PortfolioPage into the page store. As a result it will serialize the PortfolioPane and so the PortfolioModel. This model will be detached at some point and so have a small memory footprint - only its ptfID. This is good. Now the bit I struggle with. As I have now added a whole collection of PositionRow instances to the RepeatingView their Position instances will now be serialized and saved. This seems to negate the trouble I went to to make my PortfolioModel Loadable. I dont really want to have PositionRow have a LoadableModel as this will simply cause a very inefficient row-by-row fetch of each Position from the DB. The only approach that seems to work is to do this instead: for ( Portfolio ptf : getModelObject().getPositions() ) { v.add( new PositionRow(model, ptf.getKey() ) ); } so that I only need to save the key as the serializable state in PositionRow. This would seem to work but it feels a bit convoluted to me. As the model becomes more complex this approach starts to become unmanageable and makes building reusable bits harder. I hope my confusion is clear and someone can offer me a hint as to what to do. Mmm, I suppose if you tell me that I don't understand the serialization strategy used by Wicket, that might also sort me out. Many thanks in advance - Steve --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org