been thinking about listviews tonight and i think you're right. but things still get tricky. the invididual listitems in a listview currently reference the list by index. so even though the undo can give you back the components in the original listview, the underlying model might not have the same structure anymore. so the object at index 6, for example, might be something else. or it might not exist. to work, i think the listitem has to have its own first class model and not just reference the listview's list by index. so this:- I'm not sure you can just separate it as simply as value/reference. As models are under control of the end developer I see no reason why they would not create a detachable model but at some point change the object that it was referencing. Thus when they press the back button they have a page that is changing a different referenced object. We have something similar in an app I'm currently working on in that one page is a combined list/create/view/edit page so the page is the same but the id of the referenced business object changes over time. Solution: I think you have to clone the model in all undo cases.
/**
* @see IModel#getObject()
*/
public Object getObject()
{
return listView.getListObject(index);
}would have to go away. and this:
public final Link removeLink(final String componentName)
{
return new Link(componentName)
{
public void onClick()
{
// Remove listItem and invalidate listView
listView.getList().remove(index);
listView.modelChangedStructure();
}
};
}would have to remove the object from the collection by object reference and not index.
in other words, when you clone a list item's model, you currently don't really capture the actual model for that item. you currently capture just the index into the list. one /could/ try to find the root model being edited somehow (the list) and clone that too, but i'm not sure if that would be right...
- There are also some other options regarding staleness which we could define against a page:
* In some cases if a page is detected as stale there is actually no problem with just rendering the very latest version of the page. In fact this is desirable in some cases, for example I might want my shopping basket page to always show the latest basket contents so if the user goes back to a stale shopping basket page I can just send in return the latest page rendering instead.
* Another option might be that if a page is detected as stale then you always return to an associated known starting page - e.g. a summary page from which they can navigate forward again to the latest area of data that they need to work with.
By having the four options per page: stale error, undo, render latest and goto page we cover pretty much anything that most people would want to do. The advantage of this is also that we only need capture undo events for pages where this is specified as the mode (which is quite important for efficient clustering). We may also need to do something like specifying behaviour in relation to whether undo is held in the session or not (i.e. clustered/session recovery undo) and if not how the page should react - I'll put a post up on where I have got with clustering later today.
regards, Chris
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
