Re: Demystifying page serialization
I think I got it. Two things, in particular. jcgarciam pointed out the problematic line. I wasn't really creating a detachable model. So, it wasn't updating dynamically. Instead Wicket put the page in the pagestore and updated the page from there. Once that was fixed, the page updated upon each browser refresh. As KingCode pointed out, Bookmarkable pages stores state in the URL. Wicket, apparently, doesn't update these pages from the pagestore. These always updated upon each browser refresh. Thanks all. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2536347.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demystifying page serialization
Wicket will read the page *instance* from the page store, and then process the render phase of the request cycle using that instance. If you use LoadableDetachableModel (or similar models that refresh their contents) you get a refreshed page. Martijn On Thu, Sep 9, 2010 at 10:26 PM, Mike Dee mdichiapp...@cardeatech.com wrote: Does that mean if the back button is used to go back to a URL like this: http://myurl/myapp/?wicket:interface=:3 and the SHIFT-REFRESH button is used (hard refresh), that Wicket will pull the page out of its cache rather than calling the app to regenerate the page? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2533548.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demystifying page serialization
I tried this with a detachable model. I created two versions of the page,
one uses a detachable model and the other doesn't. I put a printout in the
constructor of the page. The printout appears only the first time the page
is loaded in both cases. Here is the code. What am I doing wrong?
// Detachable model
public PersonPage( int id )
{
PersonDetachableModel model = new PersonDetachableModel( id );
System.out.println( ** HERE I AM ** ); // This doesn't appear upon
RELOAD OF PAGE.
add( new Label( name, model.getObject().getName() ) );
}
public class PersonDetachableModel extends LoadableDetachableModelPerson
{
private int personId;
public PersonDetachableModel( int id )
{
personId= id;
}
public Person load()
{
Person person = db.findPerson( personId );
return person;
}
}
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2535132.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demystifying page serialization
You're not detaching your model, for one. You either need to set it
as the default model (which will automatically be detached) on the
page or manually detach it in an onDetach() method.
how are you reloading the page? How are you getting to this page in
the first place?
On Fri, Sep 10, 2010 at 5:57 PM, Mike Dee mdichiapp...@cardeatech.com wrote:
I tried this with a detachable model. I created two versions of the page,
one uses a detachable model and the other doesn't. I put a printout in the
constructor of the page. The printout appears only the first time the page
is loaded in both cases. Here is the code. What am I doing wrong?
// Detachable model
public PersonPage( int id )
{
PersonDetachableModel model = new PersonDetachableModel( id );
System.out.println( ** HERE I AM ** ); // This doesn't appear upon
RELOAD OF PAGE.
add( new Label( name, model.getObject().getName() ) );
}
public class PersonDetachableModel extends LoadableDetachableModelPerson
{
private int personId;
public PersonDetachableModel( int id )
{
personId= id;
}
public Person load()
{
Person person = db.findPerson( personId );
return person;
}
}
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2535132.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demystifying page serialization
One thing I learned (from observation) is that if the page is a bookmarkable page (gotten to via a BookmarkablePageLink) the page never reloads from the page store regardless of whether the model is detachable. But if the page is gotten to via a Link, the page always appears to reload from the page store. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2535197.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demystifying page serialization
That's right. On Fri, Sep 10, 2010 at 7:02 PM, Mike Dee mdichiapp...@cardeatech.com wrote: One thing I learned (from observation) is that if the page is a bookmarkable page (gotten to via a BookmarkablePageLink) the page never reloads from the page store regardless of whether the model is detachable. But if the page is gotten to via a Link, the page always appears to reload from the page store. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2535197.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demystifying page serialization
But why? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2535266.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demystifying page serialization
Mike, in reference to your various questions, here is my take: You are not seeing your constructor tracing print statements because it is not invoked more than once (the page object is already in the page store, with its component attached as per the constructor invocation) - all components are the same, but the data can vary depending on your model as observed. This is the case for stateful, or non-bookmarkable pages. Bookmarkable pages are re-instantiated and must be given their state if any, at construction time. That is how Wicket decides whether to go back to the page store or use a new instance. I believe Bookmarkable links are there to accomodate fast access to stateless pages or stateful pages with the state encoded in the request. On Fri, Sep 10, 2010 at 8:36 PM, Mike Dee mdichiapp...@cardeatech.comwrote: But why? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2535266.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demystifying page serialization
Also with this line, you are not taking advantage of a model itself, this is
label have an static value on it.
add( new Label( name, model.getObject().getName() ) );
try something like:
add( new Label( name, model) );
After loading your page first time, change your Person table in the db and
then hit refresh in your web browser, the component label should reflect
your changes
On Fri, Sep 10, 2010 at 6:57 PM, Mike Dee [via Apache Wicket]
ml-node+2535132-587425177-65...@n4.nabble.comml-node%2b2535132-587425177-65...@n4.nabble.com
wrote:
I tried this with a detachable model. I created two versions of the page,
one uses a detachable model and the other doesn't. I put a printout in the
constructor of the page. The printout appears only the first time the page
is loaded in both cases. Here is the code. What am I doing wrong?
// Detachable model
public PersonPage( int id )
{
PersonDetachableModel model = new PersonDetachableModel( id );
System.out.println( ** HERE I AM ** ); // This doesn't appear upon
RELOAD OF PAGE.
add( new Label( name, model.getObject().getName() ) );
}
public class PersonDetachableModel extends LoadableDetachableModelPerson
{
private int personId;
public PersonDetachableModel( int id )
{
personId= id;
}
public Person load()
{
Person person = db.findPerson( personId );
return person;
}
}
--
View message @
http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2535132.html
To unsubscribe from Apache Wicket, click
herehttp://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=.
--
Sincerely,
JC (http://www.linkedin.com/in/jcgarciam)
Work smarter, not harder!.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2535303.html
Sent from the Wicket - User mailing list archive at Nabble.com.
Demystifying page serialization
I've been reading books, articles, blogs about Wicket page serialization. I don't get it. Specifically, I don't get the need and/or benefits. Most references state that page serialization addresses the back button issue. If a user presses the browser's back button, doesn't the browser simply read the page out of its own cache? Now say the back button is used and the browser's refresh button is pressed (hard refresh with the SHIFT key held down), wouldn't one want the page to be regenerated on the server side as opposed to reloaded from Wicket's page cache? Under what circumstances is the page cache useful? I don't think I'm getting it. Any pointers to articles or explanations are appreciated. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2533538.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demystifying page serialization
The trick is that each link/form points to a specific version of your page in the cache, so you can be sure that you're dealing with the same component hierarchy. On Thu, Sep 9, 2010 at 4:17 PM, Mike Dee mdichiapp...@cardeatech.com wrote: I've been reading books, articles, blogs about Wicket page serialization. I don't get it. Specifically, I don't get the need and/or benefits. Most references state that page serialization addresses the back button issue. If a user presses the browser's back button, doesn't the browser simply read the page out of its own cache? Now say the back button is used and the browser's refresh button is pressed (hard refresh with the SHIFT key held down), wouldn't one want the page to be regenerated on the server side as opposed to reloaded from Wicket's page cache? Under what circumstances is the page cache useful? I don't think I'm getting it. Any pointers to articles or explanations are appreciated. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2533538.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demystifying page serialization
Does that mean if the back button is used to go back to a URL like this: http://myurl/myapp/?wicket:interface=:3 and the SHIFT-REFRESH button is used (hard refresh), that Wicket will pull the page out of its cache rather than calling the app to regenerate the page? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Demystifying-page-serialization-tp2533538p2533548.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
