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 >
