As igor says. getters and setters are not needed. I do it purely on the none final and none static fields.
It is not really an own serialization. Just our own way of creating a snapshot (but not serialize everything)

And a completely page is already done in 2.0. That one is saved to disk. So yes in 2.0 we could do it a bit
better. Keeping complete copies in mem is not an option.

johan



On 9/17/06, Erik Brakkee <[EMAIL PROTECTED]> wrote:


On 9/17/06, Johan Compagner < [EMAIL PROTECTED]> wrote:
how is a model attached to the component if they have to be looked up from somewhere?
Where i that lookup being done? And where is the looked up model comming from?

The model is attached to a component. It just has a unique id which must be looked up. As soon as an id is assigned, it is registered in the Page (it is still attached to the component). Subsequently, when a model must be passed to another model as a reference, the ModelReference<T> is passed instead. This model reference encapsulates a lookup of a model in the Page.

remeber Models can also be used over more then one page.

I think using a model over multiple pages introduces the same problem we are trying to solve here. When the back button is used, the different pages that used to refer to the same model object are now all of a sudden referring to different objects.

Is there any reason why one would like to share the same model object over multiple pages with support for the back button?

i am still looking into a third alternative. And that is doing the "serialization" our selfs by using reflection.
Just lookup all the fields of a model and i think maybe we could only do this for the deepest
or just walk over the complete model chaining. And do let the model references fields in takt
but do make a copy of all other fields. Store that somewhere. And when rollbacked
we just set the fields back to of all the models in the chain..
So something like this:

new CompoundPropertyModel(new PropertyModel("property1',new MyModel(value1,value2)));

then we try to build up a tree of key-values

compoundpropertymodel
                        modelObjectField -> propertymodel (not cloned)
                                                      propertyField   ->     "property" (cloned or reference copy)
                                                      modelObjectField -> MyModel (not cloned)
                                                                                        value1Field -> value1 (cloned)
                                                                                        value2Field -> value2 (cloned)

Then that is stored  in the change object.

I think the fundamental problem with this is that this approach assumes that all model manipulation is through getters and setters. In practice, there can be  many other types of methods such as  adding and removing items from collections, or arbitrary business methods that change fields of objects that are not displayed on the page. In these cases, the described serialization mechanism will fail.

And... why would we want to write our own serialization mechanism.

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.


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?

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






johan


On 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.

Cheers
  Erik


johan


On 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.

Cheers
  Erik


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

Reply via email to