grrrr.. getting late, the setter should be:

        public abstract void setObject(Object obj) {
                if (!isEquals(obj, getObject()) {
                        editedValues.put(obj);
                }
        } 

Thomas

> -----Original Message-----
> From: Maeder Thomas [mailto:[EMAIL PROTECTED] 
> Sent: Mittwoch, 6. Februar 2008 17:20
> To: [email protected]
> Subject: RE: IPropertyResolver interface for property models
> 
> 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]
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to