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
RE: Page serialization testing
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:ccr...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
IAjaxCallListener, IAjaxIndicatorAware, and ajax submittal of multi-part forms
Whenever posting multipart forms via ajax, any IAjaxCallListener or IAjaxIndicatorAware classes at play will have no impact. If the form is not multi-part, all works fine. As part of our upgrade process (from 1.4.13 to 6.0), I have converted a handful of AjaxCallDecorators to appropriate IAjaxCallListeners. All works fine whenever my forms are NOT mult-part, but as soon as a form becomes multi-part, the IAjaxCallListeners and IAjaxIndicatorAwares have no impact. I can see in wicket-ajax-jquery.js that the handlers are ignored in multipart scenarios. Is there any plan to add support for this? Any other recommended alternatives when dealing with a multi-part form?
Form processing issues and questions (particularly related to Border and ListMultipleChoice)
I am hoping that someone can shed some light upon a few questions I have around how Borders affect form processing. I have a Border that I commonly use within my application. When using this Border, I have noticed that all my FormComponents are being processed twice (validateRequired, convertInput, validateValidators, and updateModel all are called twice). I have traced this down to the fact that both Form.visitFormComponentsPostOrder and Form.internalUpdateFormComponentModels initiate a second pass when the form's parent is a Border object (although these methods are slightly different - one only looks to the immediate parent while the other traverses up all parents looking for a Border). First of all, is it expected behavior that conversion, validation, and updateModel can be called more than once per FormComponent during form processing? I would have expected that these methods would only be called once per request cycle (in particular, with updateModel). If this is not the case, I need to change my mindset a bit when it comes to developing FormComponents. Generally speaking, my implementations as well as Wicket's default FormComponent subclasses work fine when these methods are called twice. However, this is not always the case. For example, with ListMultipleChoice, a second call to these methods ends up updating the model incorrectly if my original model object value is null. The first call to updateModel in this case sets my model value to be the same instance as getConvertedInput(), which appropriately places my selected items in the model. However, on the second call to updateModel, one of the first things done is to call clear() on my model object, which clears the converted input as well (since they are the same collection). This results in the loss of my converted input, which in turn, blanks out my model. I have worked around this particular issue by insuring that my model object is never null in the first place - if null, I make sure it is an empty collection in onBeforeRender... So I have two primary questions: 1.) Should I always code expecting that it is normal behavior for convertInput/updateModel to be called on my FormComponent instances more than once? 2.) Is it necessary that Borders cause a second pass? Part of me tends to want to steer away from Borders if this is the case... although I really love what they provide me. Thanks for any insight!
