Hi,
in the branch we just checked in we implemented a first cut of what we think works great
and exactly what it should do when using replace (or later on also with add or remove).
In the MarkupContainer.replace() method we now do this first:
Page page = (Page)findParent(Page.class);
if(page != null && page.getRendering() > 0)
{
page.visitChildren(Component.class, new IVisitor()
{
public Object component(final Component component)
{
component.detachModel();
return CONTINUE_TRAVERSAL;
}
});
// first make a copy of the complete page..
try
{
ByteArrayOutputStream out = new ByteArrayOutputStream ();
ObjectOutputStream oout = new ObjectOutputStream (out);
oout.writeObject (page);
ObjectInputStream in = new ObjectInputStream ( new ByteArrayInputStream (out.toByteArray ()));
Page copy = (Page)in.readObject ();
getSession().addPage(page);
getSession().setPage(copy);
page.clearRendering();
}
catch (Exception e)
{
log.error("Renderer", e);
}
}
So we first test if this page already rendered, if this is the case then normally the replace couldn't happen.
But what we do then is create a copy.
That creating of a copy now happens with Serialization. But we could implement a Factory so that a developer can choose what ever he wants.
Like Copy Constructor, or even Clone...
Then when the copy is created that copy is being set as it was the current page for the cache (session.setPage)
and the current page itself is being added to the session and the rendering count is cleared so that it looks like a completely new page.
So if you selected another tab and then go back with the back button. the page can still be found with the exact same state (the one of the copy)
By testing this, we found some serialization errors in wicket!
Some like Page.session that is not transient (it should be and getSession() of page should test for null and if null then do Session.get()) are easy to fix.
But others and those map on the ImageResouce/IResouce (like UrlResource) are harder. Those are all not serializeable and
currently we are searching for the best way to make those serializeable . Any ideas?
But the how it works now is really great. It is completely transparent for the developer.
And can also be used for ListView.removeAll(). Then exactly the same should happen. right before the remove all make a copy of the current page
and use that copy for the cache so that a back button will map on the right listview..
If the usage of serialization is to slow or eats to much resources then a developer should be able to override this behavior and make use
of its own implementation by using for example a copy constructor.. This is ofcourse faster..But the developer has then much more work todo.
We already timed the serialization approache and it is only slow the very first time you serialize a page (1.5s) but all the following calls are 50-60ms
for very complex pages.
johan
------------------------------------------------------- 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
