I'd imagine that listview would do something like this,
dataList = listViewPropertyModel.getModelObjectAsList
for each data in dataList
onPopulateItem{
dataList.get(i)
}
dataList would only result in one call to the listViewPropertyModel,
equivalent of load() in the LoadableDetachableModel.
But apparently, the implementation does not have this step, instead it
for each listViewModel
listViewMode.getModeObject.get(i)
I guess I need to further study the mode object to understand the inner working.
The point is the model should be first absorbed/consumed by listview,
and later provided to listitem.
>if i read your code correctly you provided the listview with a
>reference to a model, not a list...
>
>-igor
>
>
>On Jan 21, 2008 7:43 PM, <[EMAIL PROTECTED]> wrote:
>> Thanks for the tip. It worked perfectly.
>> I do feel this could be a minor bug even for a fixed list
>> (might not be noticeable visually). At the time ListView is
>> created, it is provided with a predefined model object =this.getRecords()
>> which should be the state of the listview and this.getModel
>> should directly return this state. This is probably due to the program idiom
>used.
>>
>>
>>
>> >wicket is doing exactly what you told it to do
>> >
>> >you call final Object record = listItem.getModelObject(); 1000 times
>> >
>> >which in turns calls listviewmodel.getobject().get(index); where index
>> >varies from 1 to 1000
>> >
>> >listviewmodel is PropertyModel(this, "records") so when its
>> >getobject() is called (1000 times) it calls getrecords() method
>> >
>> >thus your getrecords is called 1000 times - just like you have it setup.
>> >
>> >you should read up on detachable models and loadable models - models
>> >that cache a value for the duration of a request.
>> >
>> >for example, if you replace new PropertyModel(this, "records") with
>> >new LoadableDetachableModel() { Object load() { return getRecords();
>> >}}
>> >
>> >getRecords() would only be called once per request.
>> >
>> >also if you have read the javadoc of ListView you would have noticed
>> >that it does not recommend using ListView with database driven data.
>> >ListView is made to work with lists. in a list an item is identified
>> >by its index, in a database rowset an item is identified by its
>> >primary key.
>> >
>> >you took an example that uses static data where getrecords() is a
>> >cheap call and expect it to work with database data without
>> >modifications - where getrecords() is an expensive call, dont you
>> >think that is silly?
>> >
>> >if you want to display database data i would look into DataView and
>> >DataTable. there are plenty examples in
>> >http://wicketstuff.org/wicket13/repeater/
>> >
>> >-igor
>> >
>> >
>> >On Jan 21, 2008 6:32 PM, <[EMAIL PROTECTED]> wrote:
>> >> I see. I guess I need to dig through more info on usage of api.
>> >> But I just noticed the following perhaps you can point out
>> >> surprising (to me) issue right away.
>> >> It is a simple list view display with
>> >>
>> >> class Test{
>> >> PageableListView listView = new PageableListView("records", new
>> >PropertyModel(this, "records"),
>> >> rowsPerPage) {
>> >> public void populateItem(final ListItem listItem) {
>> >> final Object record = listItem.getModelObject();
>> >>
>> >> public List getRecords(){
>> >> return <a record list from db query>
>> >> }
>> >>
>> >> }
>> >>
>> >> what I noticed that for each populateItem call, it would invokes
>> >> getRecords() (perhaps with further indexing). So it I have 1000 records
>> >> in db, it would issue 1000 query for the same result list.
>> >> What I am doing wrong here? I basically took an example class from
>wicket
>> >website and replace the fixed record list with a db query and
>> >> could not explain the extreem slowness until I found out this problem.
>> >>
>> >>
>> >>
>> >> >you are free to write your own coding strategy that checks for
>> >> >existence of these pages in session before creating a new instance.
>> >> >
>> >> >-igor
>> >> >
>> >> >
>> >> >On Jan 21, 2008 6:01 PM, <[EMAIL PROTECTED]> wrote:
>> >> >> > Would it be possible to turn a bookmarkale/stateless page object
>> >> >> > into a stateful page during a session once user first access it.
>> >> >>
>> >> >> these pages are not created until accessed...so not sure what you
>mean
>> >> >>
>> >> >> >> I meant once they are created, accessing it again (say hit refresh
>> >button
>> >> >on browser) should
>> >> >> not result in a new page object recreation, instead using a way to
>> >> >> locate the previous created object and rerender it as in a stateful
>> >> >> page.
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>>
>> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >> >>
>> >> >>
>> >> >
>> >> >---------------------------------------------------------------------
>> >> >To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> >For additional commands, e-mail: [EMAIL PROTECTED]
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
