Approaches to complex data
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 {
ListPosition 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
Re: Approaches to complex data
Gah, sorry, there were a couple of typos, let me try again
Steve Flasby wrote:
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 {
ListPosition 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 PortfolioPanel(XX, new PortfolioModel(ptfID)) );
}
}
class PortfolioPanel extends Panel {
public PortfolioPanel(String id, PortfolioModel model ) {
super(id, model);
RepeatingView v = new RepeatingView();
add(v);
for( Position pos : getModelObject().getPositions() ) {
v.add( new PositionRow(pos) );
}
}
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 Panel 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 PortfolioPanel 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 ( Position pos : getModelObject().getPositions() ) {
v.add( new PositionRow(model, pos.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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Approaches to complex data
use a refreshingview or a dataview or a listview instead of repeatingview.
-igor
On Fri, Jan 30, 2009 at 6:54 AM, Steve Flasby st...@flasby.org wrote:
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 {
ListPosition 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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
