maybe you want to use a detachable model for the person so that it is loaded from the database.
this is where public MyForm(String id, IModel personmodel) would come in handy. pass in whatever kind of model you want, and the propertymodel will use it to retrieve the object.
-Igor
On 1/25/06, Dirk Markert <[EMAIL PROTECTED]> wrote:
Martijn,where is the big advantage betweenpublic MyForm(String id, IModel personmodel) {
super(id, personmodel);
add(new TextField("name", new PropertyModel(personmodel, "name")));
}
and
public MyForm(String id, Person person) {
super(id, person);
add(new TextField("name", new PropertyModel(person, "name")));
}It can't see it.Dirk
2006/1/25, Martijn Dashorst <[EMAIL PROTECTED]>:Frank,
I see your confusion (I think).
The javadoc comment for the modelObject parameter says:
'The model object, which may or may not implement IModel'
This means that you can use POJO's directly as a parameter, and,
IModel objects that wrap an object.
For instance, you can do this:
new PropertyModel(new Person(), "name");
and
new PropertyModel(new Model(new Person()), "name");
Both property models will evaluate correctly to the name propert of
the person object. The difference is, that the first property model
uses a direct reference to the person object, and the second uses a
wrapped person object.
The advantage of the latter is that you can use specialized models
that minimize HTTPSession usage, by retrieving the model object
'on-the-fly', and still use the property models to get to the values.
The other big advantage is that you can use this in your forms:
public MyForm(String id, IModel personmodel) {
super(id, personmodel);
add(new TextField("name", new PropertyModel(personmodel, "name")));
}
This has the advantage that you don't need to know how to get at the
person object in your form component. It can come from everywhere.
Martijn
On 1/25/06, Frank Silbermann <[EMAIL PROTECTED]> wrote:
>
>
>
> The JavaDoc for the PropertyModel constructor says that its parameters are
> an IModel and an OGNL string, but I noticed that the code accepts any
> java.lang.Object as the first parameter. I discovered this when trying to
> sort out my confusion when the linkomatic example created a PropertyModel
> using "this" (the page itself) instead of an IModel.
>
>
>
> At first I thought this looked like a hack, and asked myself: "If you
> wanted to be able to accept either kind of object, why not use two
> constructors?" Then I realized that java.lang.Object is the supertype of
> everything, and maybe Java doesn't let you create overloaded constructors
> where the only difference in parameter is type versus subtype. But if the
> convenience of passing a non-IModel POJO is so important, then why not
> mention it in the JavaDoc?
>
>
>
> Or is the capability of passing a non-IModel POJO to the constructor a
> "deprecated" capability, perhaps included to ease the conversion of programs
> from earlier versions of Wicket? (If that is the case, perhaps the
> linkomatic example should be updated. The Page object could easily have
> been wrapped before passing it to the PropertyModel constructor.)
>
>
>
>
--
Living a wicket life...
Martijn Dashorst - http://www.jroller.com/page/dashorst
Wicket 1.1 is out: http://wicket.sourceforge.net/wicket-1.1
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
