we might remove the change tracking, but the interface can stay. maybe it
wont be called a versionmanager anymore...

-igor


On 9/28/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]
>
>

Reply via email to