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

Reply via email to