Eelco Hillenius wrote:
I've looked at it briefly. The main thing you need to keep in mind is
that it unfortunately is a limitation of Wicket that you can't have
references in Components that aren't serializable (unless you don't
care about back button support and turn of the second level session
cache, OR you plug in your own serialization support that doesn't need
classes to be serializable).
Thank you for your response. It is much appreciated.
As I understand it, the back button problem is defined as the
undesired triggering of a transaction subsequent to the user going
back and resubmitting. For example, let page C be a purchase
confirmation page and T be the "thank you for your purchase page"
after the user confirms a certain purchase. The user confirms a
purchase on C and the application sends T in response. If the user
clicks on the back button and resubmits C, then the application should
prevent a presumably unwanted re-purchase. Invalidating the cart when
T is sent to the user is sufficient to solve this particular
"back-button" problem.
Again, as I understand it, instead of preserving state, the back-button
problem is addressed by invalidating state. Surely, wicket is
addressing a subtler back-button problem.
In this case though, you don't really need those members, right? All
the members are used in methods that are called during construction of
the panel, so why not just pass them through those methods (or if you
don't like that, make the members transient)?
Since admittedly I don't actually understand the back-button problem, I
don't see the consequences of eliminating references to unserializable
members in my wicket components. I guess I'll have to experiment.
Alternatively, in the case of this particular problem, I could
construct a parallel serializable class hierarchy. While in the
general case such an approach could be qualified as inelegant or even
dumb, in this particular case it might the cheaper and the more
elegant solution.
Is there a wicket-example illustrating the back-button problem solved
by wicket? I looked at http://wicketstuff.org/wicket14/stateless/ but
its point was lost on me.
Eelco
On Fri, Oct 9, 2009 at 2:16 PM, Ceki Gulcu <c...@qos.ch> wrote:
Eelco Hillenius wrote:
Hi,
It looks like GenericBaseModel has a reference to a JUnit Description?
Maybe you can paste your GenericBaseModel class here?
Fortunately, my application is open source. You can find its source code at
http://github.com/ceki/mistletoe
If you look at the DescriptionPanel class [1] you'll see that it essentially
presents a junit.Description and a junit.Failure instance both of which are
non-serializable.
[1] http://tinyurl.com/yha75x8
If that's something you'll have a runtime you shouldn't ignore it if
you want to support history (the backbutton). If it's just during
testing, you can ignore it if you like.
My application is a testing platform so I can't ignore junit nor testing.
:-)
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
