Thanks Igor. That helps a lot. I am going to read the documentation again and run through some more examples. I really appreciate your time.
Gregg
On 1/18/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
the CompoundPropertyModel is one of the trickest to understand. in its essence it is a very cool model that can save you a lot of work.
basically what it allows you to do is use the component id as the property-path _expression_ of your model as well as allow child components to user parent's model.
for example...page constructor...
Person p=new Person();
Form form=new Form("form", new CompoundPropertyModel( p ));
form.add(new TextField("name"));
form.add(new TextField(" address.line1"));
form.add(new TextField("address.zip "));
notice that the text field components ive added to the form do not have a model associated with them. when a component does not have a model (model==null) it will try to search up its hierarchy to find any parent's model that implements ICompoundModel interface, and if it finds it it will use that as its own model.
so in essense every textfield i added to the form will use the form's compoundpropertymodel as its own because its the first in the upwords hierarchy that implements ICompoundModel
so when the textfield needs to retrieve the value it will ask its model. the getter/setter in the model is implemented with a Component param: IModel.getObject(Component c), this may seem strange at first, but it allows the compound property model to function.
so what the compound property model getter looks like is this
getObject(Component c) {
Object nestedObject=getnestedmodel(); // in our case retrieves the person object
// property resolver is a helper that evaluates ognl-like expressions
Object value=PropertyResolver(c.getId(), nestedObject());
}
the key above is that the property resolver's _expression_ is the component id. notice in the form add(new TextField("address.zip")); the component's id is the property-_expression_ that will be used on the person object.
so this is a really great shortcut when building forms
without it you would have to do something like this:
add(new TextField("zip", new PropertyModel(form.getModelObject(), "address.zip")));
which is much longer.
there are more uses but this is the more common one. it also allows one to create panels and populate the form very quickly. ie, i can group those form components into a panel and if i have a form bean with two person objects i can represent both of those with an instance of my panel and its easy to connect them to the actual model using compound models.
wicket also supports model chaining. so per your example you wanted to edit person which is a property of the page. to do that i would change the example above like this
Form form=new Form("id", new CompoundPropertyModel(new PropertyModel(this, "person")));
i hope you are still awake.
-Igor
On 1/18/06, Gregg D Bolinger <[EMAIL PROTECTED] > wrote:Thanks, I check out that link. It makes more since now. So would you use a CompountPropertyModel when you want to get the value of an object? Say out of a Person bean that you populated and that wasn't a page property?Gregg
On 1/18/06, Igor Vaynberg < [EMAIL PROTECTED] > wrote:the model is a locator for the underlying value object, so what it really affords you is a level of indirection.
take a simple read only example. the use of the model allows the underlying value object to change dynamically w/out the component knowing or worrying about it.
so for example new Label("id", "hello world") is nice. but its value object ("hello world") is static and doesnt change.
now suppose you want that value to change, lets say the label represents a page property and you want it to update automatically w/out having to worry about it. so now you can create a model to pull the value from the page property.
new Label("id", new PropertyModel(this, "hello"));
now everytime the label renders it will ask its model for the value object, which in turn calls getHello() on the page. and now the label always displays whatever is in the hello property of the page w/out any tweaking.
so as i said, its a very nice level of indirection that can contain any amount of logic. you can achieve some very cool behaviors due to this, but i dont have time to go into them right now. recently on the list i showed one of these here:
http://thread.gmane.org/gmane.comp.java.wicket.user/7469
if you are intereseted.
hope this explains some of it, im short on time :(
-Igor
On 1/18/06, Gregg D Bolinger <[EMAIL PROTECTED] > wrote:I blogged about it recently but I wondered if anyone had any other documentation that explains when one should use which IModel implementation? Anything other than browsing through all the example code? Thanks.
Gregg
