it has nothing to do with requiring a function to be set. the problem is that the function is free to change its mind at any moment, but we rely on it returning the same value during some fixed periods of time. if we truly want to support isvisible() we would need to cache/memoize the value for the period we assume it to be constant. but, defining these caching regions is very difficult, and maintaining them as we work on core we be even more difficult still.
-igor On Mon, Nov 29, 2010 at 6:44 PM, Eelco Hillenius <eelco.hillen...@gmail.com> wrote: >> ive run into plenty of weird problems with overrides, but maybe >> because this was in a high concurrency app where data changed >> frequently. the problems arise from the fact that the value returned >> from isvisible() can change while we are doing traversals, etc. > > Hmmm, yeah, I can see how that could be a problem. Still, in general I > find overrides to be easier to backtrack because it is a simple > function. Wicket's mutable programming model is both a boon and a bane > :-) Maybe a good solution would be to require a function to be set > (would obviously work better in say Scala than Java at this point) > that is called during the rendering preparation and which result is > put in a temporary storage as the sole way of doing this. I'd > personally like that better than supporting setVisible. > > Eelco >
