On 9/4/07, Sam Hough <[EMAIL PROTECTED]> wrote: > > Thanks Johan and Eelco, > > I'm going to consider the model as opaque as far as change tracking is > concerned. I just want an easy way to track dirty components so looks like > this is the way to go unless it is going away completely. Since so many > methods are final the only options I can think of are polling components for > change, our own build of Wicket, explicit marking or AOP. None of which > sound attractive.
If some finals are in the way, and you have a real good use case for us, we can always consider removing. We've done that in the past. As for your strategy to track dirty components... I'm really not sure now whether using Wicket's change mechanism is the best way to go. Like Johan said, what is done with it depends on the version manager in use, which depends on the session store in use. We might have to remove final from Component#addStateChange to facilitate listening to changes without having to jump through too many loop holes. I'm still wondering whether it is really the component changes you are after. If you are building something completely generic, maybe yes, and maybe this should be part of Wicket then. Otoh, I expect that typical applications are actually interested in reflecting data changes, which are typically not communicated through component changes. The problem is though, that for the sake of efficiency, we only pull data when we need it. I.e. when rendering the components. And as with Ajax you only want to do partial renders... Though one this. Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
