Re: IPropertyResolver interface for property models

[Daniel Stoch]

This is exactly how ObjectEditor default implementation would looks  
like: it contains hashmap for edited values.
Simple HashMap as a model is not a good solution, because you must  
somehow initialize it with object properties' values first. I think a  
better is to hide such details inside an interface (like  
ObjectEditor), then you can also easily cancel (revert) changes. But  
even using a HashMap you cannot simply use property models (normal  
and compound) to access values, you must implement another custom  
models for that. These models will be probably very similar to  
standard property models, the only difference is how they access  
object values = how their property resolver works :).

Daniel

On 2008-02-06, at 19:51, Johan Compagner wrote:

Why not just return a hashmap as the model object and have besides
that hashmap your real object

On 2/6/08, Daniel Stoch <[EMAIL PROTECTED]> wrote:
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]