I think this could work and in face of sharing the IModel I think it would
be needed (not sure so).
Letting the model do it itself: I think this is more explicit and direct.
At least the users sees what is going on with versioning of Models. It
somehow takes the magic out of it and is not that hard to implement once
you know Change and Objects.clone(). Also easier to debug.
Christian
On Wed, 7 Dec 2005 00:38:53 +0100, Johan Compagner <[EMAIL PROTECTED]>
wrote:
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).
--
Christian Essl
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
