At our company we set a session attribute and check for that using an ajax request. If the flag is set, we redirect to the error page.
Martijn On Sun, Apr 5, 2009 at 7:16 AM, Eelco Hillenius <[email protected]> wrote: > You'd have to rewrite the guts of SerializableChecker a bit, e.g. to > send a message to observers rather than just throwing a > WicketNotSerializableException. A default observer can throw that for > instance, but you could couple other observers, for instance one that > calls addError. One problem I expect is that I think these exceptions > are not necessarily thrown in the same thread , in which case this > wouldn't be very helpful. Unless you add flash messages (through the > session, will be displayed next request regardless of the page), but I > think that would be confusing rather than helpful. > > I guess if you rewrite enough you can always do this check in the same > request, in which case displaying in a bar would be neat. Probably > best to write that from scratch then (well reusing the checker, but do > the serializing check e.g. at the end of a request cycle. > > Eelco > > On Sat, Apr 4, 2009 at 10:42 AM, Jeremy Thomerson > <[email protected]> wrote: >> The debug bar that I am working on now can have someone call >> addError("MESSAGE") on it, and it will change to a red background color. >> When I'm finished, it will also display the errors in an overlay. >> >> I would like the SerializableChecker to be able to signify that there is an >> error on the debug bar. But I'm not familiar enough with the serialization >> guts to start digging around in there just before a (possibly) final release >> candidate. So, what suggestions do you have as to how I can accomplish >> this? Basically, I see the following two options thus far: >> >> 1. when the SerializableChecker runs, if it encounters an error, it >> sticks the error somewhere that is available to the debug bar contributor >> 1. problem I see: this is probably run way too late >> 2. another problem: possibly introduces tight coupling >> 2. the debug bar contributor somehow triggers serialization early or >> mimics serialization to see if it is indeed serializable >> 1. problem: is serializing this early (during render) even valid? >> probably not >> 2. problem: serialization check would be done an extra time. >> >> Any ideas? >> >> -- >> Jeremy Thomerson >> http://www.wickettraining.com >> > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
