Page serialization testing

["Crabb, Curtis" <cc...@iqnavigator.com>]

I am in the process of upgrading from version 1.4.13 of Wicket to the latest and greatest 6.0 build.  As part of this process, we are finally going through the work of insuring that our wicket component trees are serializable (we have bypassed the serialization process in the past due to a few large hurdles with our domain).

As part of testing the serialize/deserialize process, I wrote an IPageManager implementation (to be used only during testing) that only stores serialized pages.  Unlike the default Wicket implementation, it does not store the unserialized pages that were accessed in the latest request.  My hope with this implementation was to have consistent use of pages that were constructed via deserialization.

As I started my testing, I realize that this may not be a viable testing mechanism because it appears as though ajax requests rarely result in a call to PageManager.touchPage (WebPage prevents the page from getting dirty inside an AJAX request -> within {WebPage.dirty(boolean isInitialization)}).  So currently, any state changes that occur during ajax requests are being lost because those state changes are never saved via my PageManager.

Am I missing something here or is my evaluation correct?  Any suggestions for making this testing process viable?

Also, another question from a larger perspective:  I am curious to hear if anyone has any specific "gotchas" or any other considerations worth mentioning as part of the process of starting to use wicket page serialization and saving to disk.  In the past, we have not serialized our pages and our cache only stored to session (up to 5 pages).  I believe I have thought about many angles here, but am curious if anyone's experience in doing something similar has led to special considerations for disk space, performance, etc...

Thanks for any thoughts!

Curtis Crabb

RE: Page serialization testing

["Crabb, Curtis" <cc...@iqnavigator.com>]

To answer my own first question, I am now approaching this from a different angle and simply extending PageManager and overriding getPage to serialize and deserialize at that point... this accomplishes the testing that I would like to and avoids the ajax issues mentioned below.

But I am still curious to hear of any suggestions for things to consider during the process of converting to use page serialization and disk data store.

Thanks

-----Original Message-----
From: Crabb, Curtis [mailto:ccrabb@iqnavigator.com] 
Sent: Wednesday, August 08, 2012 1:18 PM
To: users@wicket.apache.org
Subject: Page serialization testing

I am in the process of upgrading from version 1.4.13 of Wicket to the latest and greatest 6.0 build.  As part of this process, we are finally going through the work of insuring that our wicket component trees are serializable (we have bypassed the serialization process in the past due to a few large hurdles with our domain).

As part of testing the serialize/deserialize process, I wrote an IPageManager implementation (to be used only during testing) that only stores serialized pages.  Unlike the default Wicket implementation, it does not store the unserialized pages that were accessed in the latest request.  My hope with this implementation was to have consistent use of pages that were constructed via deserialization.

As I started my testing, I realize that this may not be a viable testing mechanism because it appears as though ajax requests rarely result in a call to PageManager.touchPage (WebPage prevents the page from getting dirty inside an AJAX request -> within {WebPage.dirty(boolean isInitialization)}).  So currently, any state changes that occur during ajax requests are being lost because those state changes are never saved via my PageManager.

Am I missing something here or is my evaluation correct?  Any suggestions for making this testing process viable?

Also, another question from a larger perspective:  I am curious to hear if anyone has any specific "gotchas" or any other considerations worth mentioning as part of the process of starting to use wicket page serialization and saving to disk.  In the past, we have not serialized our pages and our cache only stored to session (up to 5 pages).  I believe I have thought about many angles here, but am curious if anyone's experience in doing something similar has led to special considerations for disk space, performance, etc...

Thanks for any thoughts!

Curtis Crabb


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org