Github user Jezza commented on the issue:
https://github.com/apache/wicket/pull/297
I mean, I can think of valid use case, but I'm not going to force it,
because I definitely think we have a very specific edge case...
We have a generic lazy load supplier panel.
It accepts a supplier, and a factory that accepts a component id, and the
supplier's result.
The reason the terminated is handy is because there's now a way to tell the
panel itself that it didn't finish normally, but as I said, I'm not gonna force
it, because I'm definitely in the minority.
About calling `getUpdateInterval` too soon, I'm assuming you mean from
`onInitialise`.
That is a bit too soon, so I'm fine with moving it into the `onConfigure`
where the `loaded` check is.
Thinking back, I can't remember why I did that...
Ah, wait, yeah, the check itself shouldn't be added in `onConfigure` due to
how the request cycle works.
It'll fire it on anything...
Side-note: This is actually how I noticed that the update interval wasn't
taken into account on the first request.
All of these seemingly fast lazy load panels were taking a second to load.
Exactly one second.
I think it's probably a good idea to remove the getUpdateInterval() call
and rely on the behaviour itself to update itself.
That way the method isn't called too soon.
I'm not sure I like keeping the behaviour of always firing a request.
An early escape makes sense, as in our case we have a cache that gets hit,
which is why we load it in a LLP, as it's not there the first time.
It does a lot for user experience especially when the user is on a poor
connection.
---
