I still think we need just an interface:

IVersionable
with 2 methods:
Serializeable getVersionObject
setVersionObject(Serializeable)

Then we must make a choice.. Models that don't implement this are cloned like we currently do or don't we do anything?
Most models in a detached state just (or should) store and id or a string.
So that can be that versionobject.

The Model class of us could implement it and return that serializeable object.

Ofcourse it sort of looks like Externalizeable interface but then we don't really serialize it anymore just store the object.

We don't have then at least the problem of anonymous models (when the use a base class or implement that set/get VersionObject themselfs)

Maybe we could move it completely to the model itself but then the burden is completely to the developer of that model.




On 12/6/05, Christian Essl <[EMAIL PROTECTED]> wrote:

Here our opionions clash. I don't want to get in a religous discussion,
but let me explain. And if there is a public way to register a Change than
please forget the following.

First I think Component.addStateChange () should be public. In Swing (after
which this is made) it is not the component but the model which records
the state change (it emits an event) (see
http://java.sun.com/docs/books/tutorial/uiswing/components/generaltext.html#undo).
And this is quite clear because in Swing as in Wicket the model is the
ruler of the data the component might not even know of change (In wicket
it is even worse because there are no model events).While models in Wicket
are something different to Swing this is the same.

It has also been repeatedly stated that versioning stops with component
(which is clear) and the user has to take himself care of versioning the
models - of course. But how should I write a  versioned Model which has no
mean to register a Change ie if it's not an inner-class?

And third Model versioning is confusing (look at this thread) some comps
do it some not, some models need it some not. Update your List and than
call Component.modelChanged() and don't forget it - of course again you
need access to the component. I think there should be some way to register
Changes for Models directly and components should not track their change.
Models should track them if they need it (and IMO most don't need to,
because of the general pull nature).


Reply via email to