On a totally different note, generalizing a bit, what we are trying to do is to version an object-graph (in-memory). Arent' there any tools available that already do this? In particular, all we want to do is to version the page object together with all components, models, and instance variables it contains.
wicket is somewhat unique. what we are trying to achieve is to make version tracking cheap on memory. undo objects are meant to be very small and contain just the necessary info to undo the change. otherwise the session memory usage would skyrocket.
Another option (alternative 4) would be to use the same mechanism we have now but in a slightly different way. Currenlty, we are simply serializing each model independently, and that is what causes the problem in the first place. Why not serialize in one go?
the problem is that the serialization needs to happen immediately because we are creating undo objects. so before you make the change we need take a snapshot of the state or create an undo object that can restore the part of the object graph you are about to modify, because models are opaque we dont know what portion of the object graph that is until we actually serialize/introspect the implementation of the model.
i think for version 2 because we are storing old pages on disk it might actually make sense to ditch the undo/redo and just clone the page every time. doing this will solve all these issues, at least as far as models in a single page go. if we backport that to 1.3 then we might ditch undo in 1.3, but this will need to be seriously profiled first.
-Igor
For instance:
/**
* Interface for defining a serializable object together with a method for putting it back.
* It contains the actual object to be serialized.
*/
interface SerializableItem {
void putBack();
}
class SerializableList implements Serializable {
private List<SerializableItem> _items;
public SerializableList() {
_items = new ArrayList<SerializableItem>();
}
public void add(SerializableItem aItem) {
_items.add(aItem);
}
public void putBack() {
for (SerializableItem item: _items) {
item.putBack();
}
}
}
Now, instead of serializing individually, add each each object to be serialized using the SerializableList. Then, serialize the SerializableList instead of the individual objects. Upon deserializing, deserialize the SerializableList. In this case, all references will remain intact. Now call putBack() on the serializableList and it will put back all serialized objects, with all references to them intact.
When we get an undo we go use our PropertyResolver to set all the properties back into the current model.
That only works if all manipulation is done through getters and setters.
johan
johanOn 9/17/06, Erik Brakkee <[EMAIL PROTECTED]> wrote:On 9/17/06, Johan Compagner < [EMAIL PROTECTED]> wrote:What is that ModelRegistry thing?
That is something which I just thought of. The only thing that would manage is a mapping of model to ids.
Does that return a model? So models are not attached to components?
Models are still attached to components, but they also have a unique id. The id must be determined by something. I just called it a model registry, but it should probably be the page.
That won't work in clustering or serialization of the http sessions.
The only thing i can think of is having a method on an interface (that extends IModel)
that is something like: getChangeState()
And then returns a change state for the current version of the model.
Exactly what would change state do? Do you just mean the memento pattern where it simply returns a representation of its state? Like Serializable getState()/void setState(Serializable).
So it serializes the current model object in it. Then when rollbacked that state will just set the right model
object back. Then no models need to be cloned.
That is the other alternative. We have two methods:
1. keep versioning non-intrusive to the model: This is the current approach. Unfortunately, this means that references to models are not 'version-safe' so you need a lookup mechanism again.
2. make versioning intrusive to the model: In this way references between models can be normal POJO references, but the model interface must be extended then.
The problem is whe can build that in all our own models. But at the moment somebody extends it they
should add data into that change model if they have there own state in that model.
That is indeed the disadvantage. Subclasses should override get/setState to return an extended state representation.. (Still don't understand what you man with changeModel).
Another disadvantage it will break all existing 3rd party model implementations. Perhaps, we can also put the additional methods in a sub interface of IModel like
interface IVersionableModel extends IModel {
Serializable getState();
void setState(Serializable aState);
}
Then we simply keep the current method for all the other types of models.
CheersErik
johanOn 9/17/06, Erik Brakkee <[EMAIL PROTECTED] > wrote:I just looked a bit at the code for ModelChange.java in wicket 2. I see the problem now. The CompoundPropertyModel is being cloned so if there is another model referring to that model, it will always refer to the wrong version of the model in case an old version of the page is requested.
A solution would be to introduce one level of indirection. Instead of directly referring to a property model in a child model, the model should refer to the model using a unique id of the model (generated by wicket internally). Wicket should then maintain a mapping of model id to model.
Then, when an old page version is requested, old versions of models are simply put in this map, and references will continue to work because of the indirection through the model id which is constant.
Reference lookups can be encapsulated using something like this:
class ModelReference<T extends IModel {
private String _id;
public ModelReference(T aModel) {
_id = ModelRegistry.getUniqueModelId(aModel); // register the model if needed and generate a unique id.
}
T get() {
... lookup the model through its id....
return ModelRegistry.getModel(_id);
}
}
Of course, there are still problems here, like when to determine that a model is no longer in use and removing it
from the administration. Perhaps we can tie the lifetime of an id to that of the page instance so that when the page is evicted the ids may be reused. In other words, the Page object would provide a getUniqueModelId() method.
CheersErik
On 9/17/06, Erik Brakkee < [EMAIL PROTECTED]> wrote:On 9/17/06, Johan Compagner <[EMAIL PROTECTED]> wrote:i agree with igor. What does this really gain?
How will versioning and then the undo to that version work???
Child components will not do versioning. Only the top-level parent will. The child components simply delegate to their parent.
Or is the problem that wicket will also create a copy of the Child model object? I was assuming that only the actual model object (Person) would be cloned on modelChanging() but not any of the models around it.
johan
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
