I'm sorry no-one replyed yet. I'm currently very bussy, and this change
has to be thought good about. Hope to get back on this on sunday.
Regards,
Eelco
Ralf Ebert wrote:
Hi,
But how do you know that the list is changed?
I don't know. I'm not looking for a way to get this done
automatically, this isn't possible at all. I'm looking for a way to
decide myself if I want to throw away generated components or if I
want to update them from (maybe changed) list data.
If you are having that kind of models (mostly selects from a
database where also inserts and deletes can occur on)
then you have to implement youre own ListItemModel anyway (so that
you don't depend on index but can hold
you're own id (the db pk) in that model.
Well yes. But as most database entity objects implement a equals
method comparing database primary keys, this could be used to build a
default ListItemModel which will work in most cases and will never
match to a wrong ListItem in any case.
I think if you want these kind of things. You have to have some
greater model (in the ListView itself)
where you hold the state of the listems for a specific id (db pk)
so that when you make a listitem
you are checking the ListViews special model for special data.
Hmm, I think this breaks the concept of components. Lets look at a
simple example. I have a list of companies. The model is a list of
simple Company object from some database. By default, the
ListView.populateItem generates CompanyPanels. These panels can be
collapsed to a CompanyFullPanel, which simply will show more data.
This behaviour belongs to the component, the list shouldn't know
anything about it. From my point of view this kind of state
information should be associated with the component itself (for
example by some property value or by exchanging a component instance
for another). Maybe this point of view is wrong, as I said already,
I'm not really sure. Putting this in the model itself would be quite
messy, because the model is provided by some persistence layer. I
wouldn't extend this with view state information... How would you
implement something like this?
For the ListView itself, I would like to have something like a way to
set the PropagatingBehaviour with behaviours like this:
- PROPAGATE_EVERYTIME -> the current behaviour, the components get
cleaned away all the time, propagateItem gets called all the time
- PROPAGATE_FIRST_TIME -> components gets called only the first time,
but never again (even if a item is added to the list)
- PROPAGATE_UPDATE -> propagateItem gets called all the time and is
responsible for cleaning/generating/updating the component itself (so
the ListItem could contain components already, but doesn't need to).
This will also give you a ListItemModel by default which is based on
equals.
As I will need something like this in my application, I would be
willing to implement this for the default ListView. What do you
think? (respectively, do you think this would integrate well with
Wicket and could maybe even get to work with the PageAbleList?)
Regards,
Ralf
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar
happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted
by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
