If I understand this correctly, you're trying to keep an overlay while
editing an object. Why not do this:
class OverlayModel extends Model {
OverlayModel(Map editedValues, IModel underlyingModel, String
propertyName) {
...remember the parameters in instance variables
}
public Object getObject() {
if (editedValues.containsKey(propertyName)) {
return editedValues.get(propertyName);
} else {
return underlyingModel.getObject();
}
}
public abstract void setObject(Object obj) {
if (isEquals(obj, getObject()) {
editValues.put(obj);
}
}
}
As underlying models, you would use PropertyModel instances. When you
want to revert the values, you just clear the Map.
Thomas
> -----Original Message-----
> From: Daniel Stoch [mailto:[EMAIL PROTECTED]
> Sent: Mittwoch, 6. Februar 2008 16:31
> To: [email protected]
> Subject: Re: IPropertyResolver interface for property models
>
> On Feb 6, 2008 3:45 PM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > If we has such an interface then we need to rewrite most things
> > because now its just a static method and then we need to
> have instances.
>
> I know that. It is not a simple change.
>
> > i guess you want then to have AbstractPropertyModel to have a
> > getPropertyResolver method that you can override and give something
> > else back?
>
> Yes exactly.
>
> >
> > But i still dont get what you really have What is your model object
> > eventually where a property model works on?
> >
>
> I try to better explain this. When editing object I don't
> want to store changes directly to this object (eg. until form
> submit), but these edited values are "cached" in special ObjectEditor:
>
> public interface ObjectEditor extends IClusterable {
> Object getEditedObject();
> Object getPropertyValue(String propertyExpression);
> void setPropertyValue(String propertyExpression, Object value);
> void commitChanges();
> void cancelChanges();
> }
>
> Sample use:
> Form form = new Form("formId", new
> EditorCompoundPropertyModel(new ObjectEditorImpl(baseObjectModel)));
> where: baseObjectModel is a model (or can be directly any Serializable
> object) with object to edit.
> Inside EditorCompoundPropertyModel EditorPropertyModel is
> created (instead of PropertyModel) which plays with ObjectEditor.
>
> When you change value in form component (eg. DropDownChoice with
> wantOnSelectionChangedNotifications=true) then a new value is
> stored in ObjectEditor (by calling setPropertyValue()) and
> base edited object stays unchanged. Form components to get
> value for display use EditorPropertyModel and this model
> getObject() method calls
> ObjectEditor.getPropertyValue() which checks if current
> property value has been changed: if yes then this value comes
> from ObjectEditor cache, otherwise it comes directly from
> edited object. My own implementation of IPropertyResolver
> would call ObjectEditor getPropertyValue/setPropertyValue methods.
>
> Such ObjectEditor allows me to track changes in my object,
> original object stays unchanged until I commit changes. When
> user press "Cancel" button I can revert all changes by
> ObjectEditor.cancelChanges(), I can edit non-serializable objects, ...
>
> My proposition with IPropertyResolver is for discussion only.
> It is not a thing "we must have" :).
> By now, I have already implemented my own
> EditorPropertyResolver and EditorCompoundPropertyResolver
> which play with such ObjectEditor.
>
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
