Phil Kulak wrote:
It does, thank you. But in your example, won't the model object be a
list, not the actual object? And if it is the object, wouldn't it be
the wrong object if the underlying datastore had changed between
requests?
In my example there are two things to notice:
1. the button/link is added to the ListItem, not the ListView
2. the onClick is executed some time after the render, in a new RequestCycle
due to 1., the model object I ask for in the onClick() with
'getParent().getModelObject()' will be the object pointed to by the
ListItem model, and that will be item X. Due to 2, it is usually not
possible to use a direct reference to the object, bound at render time.
Using getParent().getModelObject() allows Wicket to re-wire the model
(list and elements).
As for it being the wrong object, that is true, given that the default
List model uses the index of the objects in the list (0, 1, 2, 3, 4,
etc) to resolve elements. The ListView I believe allows you to override
model object creation, in order to allow you to use for example the
primary key as an index. Look at ListView.getListItemModel(IModel,
index)
(http://wicket.sourceforge.net/apidocs/wicket/markup/html/list/ListView.html#getListItemModel(wicket.model.IModel,%20int))
for more information.
But this is always a concern when doing multi user application
programming, not a specific Wicket one ;-). The only solution I can see
which may solve the changed elements of the list problem is to store the
list and all elements in the session and reuse that when the request is
handled. For fairly long lists this will become a memory and scalability
concern. But it won't account for objects that have been deleted by
other users during the rendering of the page and the handling of the
request. The object will still be in your session stored list, but when
you want to perform some action on it, your persistence layer will be
unable to find the original object.
Martijn
-Phil
On 6/19/05, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Phil Kulak wrote:
So, as long as I don't make something final, am I alright?
That was not what I meant. When you make things final, you keep
references to those objects. You can make things final, but you /really/
need to know what will happen then.
For
example, how about not using an inner class:
final PageableListView list = new PageableListView("rows", data, 10)
{
public void populateItem(ListItem listItem)
{
MyObject value = (MyObject) listItem.getModelObject();
listItem.add(new Label("name", value.getName()));
}
};
It looks to me here like the reference to the "name" String will live
on between requests, but that the object itself and all other
properties should get garbage collected. Is that right?
True, but that was not your question. You tried to use one instance of
an object both at render time and when the request is processed.
The problem /may/ arrize when you have different moments of refering to
the objects (i.e. storing references to them during render time and
using those when the request gets handled) or when you use
REDIRECT_TO_RENDER. Using Hibernate you may experience objects that
aren't attached to a Hibernate session.
If you keep a 'hard' reference to the objects, they won't get attached
when handling the request. So you have to use the getModelObject()
method to retrieve the object. This will attach the model, and give you
the correct object (fresh from the database).
I hope I make some sense to you.
Martijn
On 6/19/05, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
The problem is that populateItem() is called at render time, and that
the onClick() is called when you have been to the client and are
processing the component listener. I have falled into this trap myself,
and I can only advise you to use the following code, which is a lot more
safer in any context:
final PageableListView list = new PageableListView("rows", data, 10)
{
public void populateItem(ListItem listItem)
{
listItem.add(new Link("sjs") {
public void onClick() {
MyObject value = (MyObject) getParent().getModelObject();
System.out.println(value.getName());
}
}
};
Note that all final keywords have disappeared and no hidden magic is
remaining on keeping references to object between render and handling time.
Martijn
Phil Kulak wrote:
Maybe it's just late, but I can't seem to answer this question myself.
Will each model object in my list exist after the request has finished
with the following code, assuming that the list is wrapped in a
detachable model:
final PageableListView list = new PageableListView("rows", data, 10)
{
public void populateItem(final ListItem listItem)
{
final MyObject value = (MyObject) listItem.getModelObject();
listItem.add(new Link("sjs") {
public void onClick() {
System.out.println(value.getName());
}
});
}
};
or how about this:
final PageableListView list = new PageableListView("rows", data, 10)
{
public void populateItem(final ListItem listItem)
{
final MyObject value = (MyObject) listItem.getModelObject();
final String name = value.getName();
listItem.add(new Link("sjs") {
public void onClick() {
System.out.println(name);
}
});
}
};
------------------------------------ -------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
