Yeah, something like that. either dirty() or something else. Point it
it would be just one call without tracking each change. And for
HttpSessionStore, we could still support it, but only with one (most
recent) version per page instance. Thus no page versioning without
secondlevelcachesessionstore. But that is for 1.4 or later of course.
-Matej
On 9/29/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> And then dirty bumps up the version number?
>
> again VersionManager is still used extensively even with the slc
> It takes care of the version numbers (normal and ajax)
>
> so if you have page.dirty() which contracts is now update in the session
> then we also suddenly bump up the version number??
> of course component.setVersioned() can't be ditched because developers
> should be able to disable versioning (backbutton support) for a page
>
>
> johan
>
>
> On 9/29/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
> >
> > 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]
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
