yes we do we use it still extensively we dont cache the changes anymore those are gone, but we still uses it to bump up the versions else how can we do that?
johan On 9/29/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > > On 9/27/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > the problem is that that still not really does auto dirty.. > > Because where does it end? just add/remove/visitble/enable? > > The nice thing is we have already something like that: thats page > versioning > > with the undo/change map. > Don't get too attached to it :) We should remove it in the next > version, doesn't make much sense for 2nd level cache session store :) > > -Matej > > > If we extend that a little bit then we could have something like > > componentChanged(component) on a page (or somekind of listener) > > and that component did trigger it self what ever did happen on it > (getting a > > child, settting the visibility, or setting an internal none wicket core > > property) > > > > johan > > > > > > > > On 9/26/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > On 9/26/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > but this discussion is not just about getter/setters (i don't care > about > > > > those) > > > > but also for add and remove.. then we are getting into some other > stuff > > > > > > Yes. Getters/ setters are less tricky. Though I'm still not breaking > > > in sweat when I imagine removing final on add and remove. > > > > > > Eelco > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
