On 9/29/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> yeah, so we keep the actual core events we support in the interface, like
> oncomponentadded(component) but remove all the Change objects.
>
> when a user changes the property they then have to call dirty(); personally
> i think we can just serialize every time and not require the user to call
> dirty() just assume it is after every request. not sure how wasteful that
> is...maybe if the user sets a different response page we assume the previous
> page is not dirty unless dirty() was called explicitly...
Yeah, that's a good point. Current state is as if dirty() was called
every request. I think if anyone needs to tune this, we should provide
way of marking page not dirty, which people who really have lot of
small request that don't do anything (e.g. polling) could use. I
remember doing such thing for thoof to suppress page serialization for
ajax polling, but that was rather trivial to do.

-Matej
>
> -igor
>
>
> On 9/28/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >
> > but then still we have the event..
> >
> > johan
> >
> >
> >
> > On 9/29/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
> > >
> > > newVersion();
> > > looks much better to me than addStateChange(new
> > > ChangeThatIsNotUsedAnyway() { public void undo().... });
> > >
> > > -Matej
> > >
> > > On 9/29/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > > > 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]
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > 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