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
