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]
