Hi,
It sounds like you know what you are doing, but I just want to check why
you chose "myObject" as a variable name in your example?
If you are properly using detachable models and do not want to serialize
a large object graph, "myObject" needs to be a loadable detachable
model, and not an actual object in your example.
"myLDM" or "myObjectModel" would be a more logical name.
In my experience it doesn't matter where you create your models, because
using a compound property model will automatically create propertymodels
on your nested components anyway. Each component needs its own model
anyway, to get and set its value.
Met vriendelijke groet,
Kind regards,
Bas Gooren
Op 25-6-2013 16:20, schreef gmparker2000:
Considering two alternative ways to set a model:
...
final CompoundPropertyModel myModel = new
CompoundPropertyModel(myObject);
control1.setModel(myModel.bind("field1"));
control2.setModel(myModel.bind("field2"));
control3.setModel(myModel.bind("field3"));
...
and
...
control1.setModel(new PropertyModel(myObject, "field1));
control2.setModel(new PropertyModel(myObject, "field2));
control3.setModel(new PropertyModel(myObject, "field3));
...
are there any performance benefits of one over the other? I profiled each
and they appear equivalent from the number of objects created point of view.
I just want to make sure that option two isn't doing something like
serializing "myObject" for each control. It doesn't appear that this is
happening but wanted to make sure.
We are binding controls to fairly large nested Java Objects. Other than
making sure to use LoadableDetachable models where possible are there any
other strategies for making sure performance is optimal? For example, would
setting the model on the form rather than on each control have any
performance benefit?
Thanks
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Model-performance-question-tp4659771.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
