Ok, you need to debug whats in a Model when it is added to
a Component. So, in setModelImpl which is called by the
Component constructor you add code to get the object
out of the Model (if its not null, of course) by calling
model.getObject():
void setModelImpl(IModel<?> model)
{
if (model != null) {
System.out.println("Component.setModelImpl: model.object="+
model.getObject());
}
.....
}
Well, just adding this simple code causes a JUnit test to fail.
(And, if you added this debugging a couple of editing cycle prior
to running all the tests, you've got the problem of even knowing
that this is the offending code.)
Why? Give up.
Its because in a Component's constructor the Component has not
yet been added to its parent Component. Thus, the Component's
path only has it as a member. Which means that if the Model
was a ResourceModel, which BTW is wrapped!!!, calling getObject
gets the wrong path for the resource, the resource lookup
fails, and the world ends.
For most folk this is never a problem, even for most developers
because they are making changes to a working Wicket core.
But for me, on the other hand, porting it to Scala where only
bits and pieces worked originally, I ran into this kind of
hidden side effect .... well, it seemed like all the time, but
it was once and a while ... but it take time to figure out the
issue.
Anyway, amazing that simply asking a model for its inner object
can end the world if you do it at the wrong place.
Ok, all software is fragile like this - one thing wrong that
bang - but it took an hour to find the little innocuous bit of
code.
[I actually put code, kind of like a constraint, in setModelImpl
to make sure that any model added never had, as an object,
an Option: Some(value) or None; looking for a totally unrelated bug.]
I feel better now, thank you for your time and patience.
Richard
--
Quis custodiet ipsos custodes
