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

Reply via email to