The contract is more or less this:
if you pass null into the call then the model object is guaranteed to give the "root" object of the model.
The "root" object is pretty much always the object that is specified through the constructor.
And yes this also is true for PropertyModels because there you specify a object and the property (so looking at
the constructor the root object of a property model is the combination of the object and the property _expression_)
Normally a developer should never have to specify anything, it can always be null because most of the times you always
want the object that you see as the root.
for example:
component.getModelObject () should always be: component.getModel().getObject(null)
The problem is that this is not the case in 1.2. Because we implemented generics how in 2.0 we did see the flaw in our models
when using compound models:
Form<Person> form = new Form<Person>("person",new CompoundPropertyModel<Person>(new Person()));
TextField<String> field = new TextField<String>("name");
Now one example why you shouldn't give the component with it when you just want to object out if it:
form.getModel().getObject(form)
This will result in an error. Because the the compound property model will try to get the propertyt "person" (thats the id of the form) from the Person object.
So to get the "root" object you should do:
form.getModel().getObject(null)
that will return the Person.
now the textfield:
textfield.getModelObject() will return the <String> name of the person. Because it will inherited the forms model. and on that model it will call:
model.getObject(this);
so thats fine, But what should happen if you do this:
textfield.getModel().getObject(null)
By the same semantics of the form. It should return the "root" object of the textfield and for that textfield it is still defined as the String name.
But that will return Person. So textfield.getModelObject() != textfield.getModel().getObject(null) that is wrong.
in 2.0 this is already fixed. And i guess backporting this fix to 1.2 would be a good thing.
So pretty much the easiest defnition to know is:
component.getModelObject() == component.getModel().getObject(null)
And you as a developer shouldn't have to give anything in that getObject() call normally. Only if you do your own special things.
johan
On 6/1/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
Plus those methods are redundant. It would just clutter the interface.
The contract is well defined. Maybe javadoc of get/setModelObject should
be improved a little and state explicitly what the argument is and how
it is used?
-Matej
Igor Vaynberg wrote:
> and what should that paremeterless override pass in to the
> getObject(Component c)? null? that will work, but will break down if you
> have a compound model - and more often then not you do.
>
> so i dont know if this is such a good thing
>
> -Igor
>
>
> On 6/1/06, *Aaron Hiniker* <[EMAIL PROTECTED] <mailto: [EMAIL PROTECTED]>>
> wrote:
>
> +1
>
>
> On Wed, 2006-05-31 at 20:47 -0600, VGJ wrote:
>> I might just be nit-picking here...but it might be nice to have a
>> parameter-less override of getObject....just for prettiness ;) It
>> might be more intuitive for the first-time user as well? It would
>> be more apparent, IMO, if you could just call model.getObject()
>>
>> Just a thought...
>>
>> On Wed, 2006-05-31 at 22:35 +0200, Matej Knopp wrote:
>>> :) Yeah, getObject is a little confusing at the beginning. The parameter
>>> is mostly used in compound models (CompoundPropertyModel) where the
>>> model is shared between multiple components to determine which component
>>> is setting/getting the value.
>>>
>>> -Matej
>>>
>>> Vincent Jenks wrote:
>>> > Excellent, that's perfect. The part I was unsure about was what to
>>> > pass for the arguement for getObject()....
>>> >
>>> > Thanks Matej!
>>> >
>>> > On 5/31/06, Matej Knopp <[EMAIL PROTECTED] <mailto: [EMAIL PROTECTED]>> wrote:
>>> >> Suppose you have
>>> >> IModel model = new LoadableDetachableModel() { ...
>>> >>
>>> >> you can get the model any time:
>>> >> List<Item> myItems = (List<Item>) model.getObject(null).
>>> >>
>>> >> First time you call getObject the model is attached (list is loaded).
>>> >> Until it's detached, getObject(null) will always return the loaded list.
>>> >>
>>> >> -Matej
>>> >>
>>> >> Vincent Jenks wrote:
>>> >> > If I were just displaying the lists in a ListView that'd be fine,
>>> >> > however I'm not using it that way.
>>> >> >
>>> >> > Suppose myDetachedModel is being displayed in a ListView and on each
>>> >> > iteration, I'm grabbing a value from the database (here's where I need
>>> >> > another detachable model) and doing calculations against it - for each
>>> >> > iteration in the ListView loop.
>>> >> >
>>> >> > In other words, I just need access to the raw object data in it's real
>>> >> > data-type after I've loaded it into a detachable model - my question
>>> >> > is simply that, how do I get it back to its original type.
>>> >> >
>>> >> > On 5/31/06, Matej Knopp < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>>> >> >> I'm not sure I understand you but you load the collections separately?
>>> >> >> Can't you just do something like this?
>>> >> >>
>>> >> >> class MyPage extends Page {
>>> >> >> public MyPage() {
>>> >> >> IModel m1 = new LoadableDetachableModel() {
>>> >> >> Object load() {
>>> >> >> return [load collection 1];
>>> >> >> }
>>> >> >> }
>>> >> >> add(new ListView("l1", m1) {
>>> >> >> ...
>>> >> >> });
>>> >> >>
>>> >> >> IModel m2 = new LoadableDetachableModel() {
>>> >> >> Object load() {
>>> >> >> return [load collection 2];
>>> >> >> }
>>> >> >> }
>>> >> >> add(new ListView("l2", m2) {
>>> >> >> ...
>>> >> >> });
>>> >> >>
>>> >> >> }
>>> >> >> }
>>> >> >>
>>> >> >> Matej
>>> >> >>
>>> >> >> Vincent Jenks wrote:
>>> >> >> > I've got a page where I need to call data from the EntityManger
>>> >> (EJB3)
>>> >> >> > several times in a single page....which means I'd need to have
>>> >> several
>>> >> >> > detached-models in the page.
>>> >> >> >
>>> >> >> > Once I put these objects and/or collections of objects into a
>>> >> >> > detachable model, what's the best way to cast them back out to their
>>> >> >> > original types?
>>> >> >> >
>>> >> >> > It seems like a silly question but I'm having trouble w/ it. If I
>>> >> >> > only had one detached model I realize I could use setModel(...) and
>>> >> >> > grab it w/ getModelObject() - but I've got 3-4 collections and they
>>> >> >> > can't all be the page model, can they?
>>> >> >> >
>>> >> >> > Thanks!
>>> >> >> >
>>> >> >> >
>>> >> >> > -------------------------------------------------------
>>> >> >> > All the advantages of Linux Managed Hosting--Without the Cost and
>>> >> Risk!
>>> >> >> > Fully trained technicians. The highest number of Red Hat
>>> >> >> certifications in
>>> >> >> > the hosting industry. Fanatical Support. Click to learn more
>>> >> >> >
>>> >> >>
>>> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
>>> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642>
>>> >> >> > _______________________________________________
>>> >> >> > Wicket-user mailing list
>>> >> >> > Wicket-user@lists.sourceforge.net <mailto:Wicket-user@lists.sourceforge.net>
>>> >> >> > https://lists.sourceforge.net/lists/listinfo/wicket-user
>>> <https://lists.sourceforge.net/lists/listinfo/wicket-user>
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> -------------------------------------------------------
>>> >> >> All the advantages of Linux Managed Hosting--Without the Cost and
>>> >> Risk!
>>> >> >> Fully trained technicians. The highest number of Red Hat
>>> >> >> certifications in
>>> >> >> the hosting industry. Fanatical Support. Click to learn more
>>> >> >>
>>> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
>>> < http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642>
>>> >> >> _______________________________________________
>>> >> >> Wicket-user mailing list
>>> >> >> Wicket-user@lists.sourceforge.net <mailto:Wicket-user@lists.sourceforge.net >
>>> >> >> https://lists.sourceforge.net/lists/listinfo/wicket-user
>>> < https://lists.sourceforge.net/lists/listinfo/wicket-user>
>>> >> >>
>>> >> >
>>> >> >
>>> >> > -------------------------------------------------------
>>> >> > All the advantages of Linux Managed Hosting--Without the Cost and Risk!
>>> >> > Fully trained technicians. The highest number of Red Hat
>>> >> certifications in
>>> >> > the hosting industry. Fanatical Support. Click to learn more
>>> >> >
>>> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
>>> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 >
>>> >> > _______________________________________________
>>> >> > Wicket-user mailing list
>>> >> > Wicket-user@lists.sourceforge.net <mailto:Wicket-user@lists.sourceforge.net>
>>> >> > https://lists.sourceforge.net/lists/listinfo/wicket-user
>>> <https://lists.sourceforge.net/lists/listinfo/wicket-user>
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> -------------------------------------------------------
>>> >> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
>>> >> Fully trained technicians. The highest number of Red Hat
>>> >> certifications in
>>> >> the hosting industry. Fanatical Support. Click to learn more
>>> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
>>> < http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642>
>>> >> _______________________________________________
>>> >> Wicket-user mailing list
>>> >> Wicket-user@lists.sourceforge.net <mailto: Wicket-user@lists.sourceforge.net>
>>> >> https://lists.sourceforge.net/lists/listinfo/wicket-user
>>> < https://lists.sourceforge.net/lists/listinfo/wicket-user>
>>> >>
>>> >
>>> >
>>> > -------------------------------------------------------
>>> > All the advantages of Linux Managed Hosting--Without the Cost and Risk!
>>> > Fully trained technicians. The highest number of Red Hat certifications in
>>> > the hosting industry. Fanatical Support. Click to learn more
>>> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
>>> < http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642>
>>> > _______________________________________________
>>> > Wicket-user mailing list
>>> > Wicket-user@lists.sourceforge.net <mailto: Wicket-user@lists.sourceforge.net>
>>> > https://lists.sourceforge.net/lists/listinfo/wicket-user
>>> < https://lists.sourceforge.net/lists/listinfo/wicket-user>
>>> >
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
>>> Fully trained technicians. The highest number of Red Hat certifications in
>>> the hosting industry. Fanatical Support. Click to learn more
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
>>> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 >
>>> _______________________________________________
>>> Wicket-user mailing list
>>> Wicket-user@lists.sourceforge.net <mailto:Wicket-user@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/wicket-user
>>>
>
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
