go ahead!
Jon Carlson wrote:
Thanks Johan, Can I create a wiki page with your answer?
On 7/21/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
Is there some documentation somewhere describing how Wicket solves the
Back button problem? My co-worker using JSF has been running into
lots of back-button problems, which makes me realize that I really
don't understand how best to use Wicket to avoid some or all of them
myself.
No docs yet, sorry. Maybe one of my collegues would like to do a short
explaination? Gili is the one that came up with the idea btw.
Wicket back button support is based on the same principles of the
Undo/Redo support in swing.
If you have page versioning enabled (thats default) then everything you
do on the component level is recorded
So setting the visibility flag is recorded as a Undoable Change for a
specific version of that page, The same is for
replacing components in a page we record the Remove of the old
component and the Add of a new component.
When you do something like this then the version number of the page is
bumped up one. As you can see that in the links
that are generated to that page.
Then when a action comes in to that page with a smaller version number.
Then everything that was in recorded
from the largest version to the version you want are Undo ed.
So for exampe a visibility Recorded on a component is stored in this class:
protected class VisibilityChange extends Change
{
private final Component component;
private final boolean isVisible;
VisibilityChange(final Component component)
{
this.component = component;
this.isVisible = component.isVisible();
}
/**
* @see wicket.version.undo.Change#undo()
*/
public void undo()
{
component.setVisible(!isVisible);
}
}
And that undo is called when an older version is encountered. and the
undo method will invert the visibility...
Looking now at that code i think holding the visibility flag isn't needed..
this should also work i believe:
component.setVisible(!component.isVisible());
But i am not sure.. Is it always the invert what a component is now. Or
what it was then...
You as a developer must record the change if you want model changes to
be recorded.. That is something
we can't really do as a framework. (because models can be anything,
implemented by everybody)
See Component.modelChanging (should be called before the model is changed)
and the Component.modelChanged (should be called after the model is changed)
For back button support the first (modelChanging) is the importand one.
But i hope this makes it a bit clearer how the Back button based on
Undoable changes is working..
johan
-------------------------------------------------------
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_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
