On Wed, 7 Dec 2005 15:23:22 -0800, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
I still do not think we need to provide a public setStateChange() method,
but maybe i am wrong. I think if pojo wants to implement its own
versioning
it is out of scope of wicket. you can always call Page.getVersion() and
do
your own rollback.
Or you can implement your own Page{addPublicStateChange()} ;)
What may help is maybe having two interfaces IModelVersionable { Change
getModelSnapshot() } and IModelObjectVersionable { Change
getModelObjectSnapshot(); } to let the model control how it creates
snapshots of objects and of itself.
then it can work like this
if modelobjectchanging is called:
IModel model=getModel();
if (model instanceof IModelObjectVersionable) {
// here a detachable model would have to return null because we have
no
way of knowing if the underlying object reference is transient
Change
change=((IModelObjectVersionable)model).getModelObjectSnapshot();
} else {
Change change=new Change() { Object
old=Objects.clone(model.getModelObject());
undo { model.setModelObject(clone); }
}
if (change!=null) {addStateChange(change);}
if modelchanging is called then we do the same but for the model itself
not
for its model object
I like this. You turn off versioning by returning null. Two minor remarks:
I think you should not check on the first IModel but on the deepest nested
or the first nested which is IModelObjectVersionable. Second maybe the
default (if not interface implemented) should be off, because of the
transient Detachables and my personal taste. It is a question of what is
needed more often and you have more experience there.
But I'd say as it is it is good. I was heading in the same direction just
slower.
however as you can see this would cause a paradigm shift of how
detachable
models work, it is no longer enough to simply declare the reference as
transient, you need to implement IModelObjectVersionable and return
null. so
there are two things you need to do. maybe there is a more elegant
solution
that i do not see yet.
Don't realy understand this. I thought currently IDetachables should
onDetach set the reference to null at the end of the request and if they
want to be versioned they should (currently) keep the reference
non-transient otherwise it will be lost with cloning.
I also dont know about all these instanceof checks we would introduce. is
that still a big performance concern?
-Igor
Not sure, wheter this is only an old performance-myth. Would be intresting
how it compares to all the reflection with CompoundPropertyModel etc and
Objects.clone(). I think in this light they are fast.
Christian
___________________________________________________________
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user