You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Daniel Stoch <da...@gmail.com> on 2008/02/06 13:58:13 UTC
IPropertyResolver interface for property models
Hi,
I'm developing custom IModel implementation which will be used as a
model in forms. This model is able to record changes made by a form in
the editing object (POJO). I do not store this changes directly to the
base object, but they are stored somwhere inside this model (eg. in a
Map of properties). Then when I try to read a property value firstly I
check if this value was modified, if so then value stored inside a
model is returned, if value was not modified property value from the
base (original) object is returned. There are some more things in this
model implementation, but they are not important in context of current
message.
Now I want to use standard property models to couple my IModel
implementation with form and form components. But the problem is that
all of these classes (AbstractPropertyModel, PropertyModel, etc.) use
PropertyResolver for geting/seting property values, so it is done
using reflection on object inside a model. These calls to
PropertyResolver (and PropertyResolverConverter) are "hardcoded" in
theirs implementations. If I can define my own PropertyResolver then I
will be able to use these property models with my custom model. Maybe
we should define IPropertyResolver interface with methods similar to
these in PropertyResolver and then in "PropertyModel" classes define a
method getPropertyResolver() which can be overriden in descending
classes? Of course in the PropertyResolver all methods could not be
static then. Another possible solution would be to pass
IPropertyResolver implementation (or better IPropertyResolverProvider
with getPropertyResolver() method) in property models constructor call
to allow customization of "property resolving mechanism".
This is a comment to AbstractPropertyModel class:
* Serves as a base class for different kinds of property models. By
default, this class uses
* {@link PropertyResolver} to resolve expressions on the target model
object. Note that the
* property resolver by default provides access to private members and
methods. If guaranteeing
* encapsulation of the target objects is a big concern, you should
consider using an alternative
* implementation.
"By default, this class uses PropertyResolver..." - but there is no
way to easy change this to some another resolver. The only way is to
override all of these getObject(), setObject(), getObjectClass(),
getPropertyField(), getPropertyGetter(), getPropertySetter() methods.
Ok I know, I can do that and probably I will do, by maybe it is worth
to think if extracting such interface as IPropertyResolver is a good
concept?
Best regards,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: IPropertyResolver interface for property models
Posted by Maeder Thomas <th...@ecofin.ch>.
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:thomas.maeder@ecofin.ch]
> Sent: Mittwoch, 6. Februar 2008 17:20
> To: users@wicket.apache.org
> 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:daniel.stoch@gmail.com]
> > Sent: Mittwoch, 6. Februar 2008 16:31
> > To: users@wicket.apache.org
> > Subject: Re: IPropertyResolver interface for property models
> >
> > On Feb 6, 2008 3:45 PM, Johan Compagner
> <jc...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: IPropertyResolver interface for property models
Posted by Daniel Stoch <da...@gmail.com>.
Thanks for your response. Your solution looks interesting and even
quite similar to mine, but... :)
My ObjectEditor interface is like your "Map editedValues, IModel
underlyingModel" coupled together. But underlyingModel in my solution
holds the whole object, not a single property:
Object getEditedObject() {
return underlyingModel.getObject();
}
I have original object and edited values stored inside one
ObjectEditor instance (therefore in one model). I can have a different
implementations of this interface. In your solution you must have 2
models for each property (one overlay model and one underlyingModel).
Another thing is maybe less important, but EditorPropertyModel and
CompoundEditorPropertyModel works the same way like standard property
models when object passed to them is not an ObjectEditor.
According to your concept ObjectEditor could have a method:
IModel getPropertyModel(String propertyExpression); // or maybe
createPropertyModel ?
instead of:
Object getPropertyValue(String propertyExpression);
void setPropertyValue(String propertyExpression, Object value);
Daniel
On Feb 6, 2008 5:20 PM, Maeder Thomas <th...@ecofin.ch> wrote:
> 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
>
>
> > 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();
> > }
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: IPropertyResolver interface for property models
Posted by Maeder Thomas <th...@ecofin.ch>.
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:daniel.stoch@gmail.com]
> Sent: Mittwoch, 6. Februar 2008 16:31
> To: users@wicket.apache.org
> Subject: Re: IPropertyResolver interface for property models
>
> On Feb 6, 2008 3:45 PM, Johan Compagner <jc...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: IPropertyResolver interface for property models
Posted by Johan Compagner <jc...@gmail.com>.
Exactly PR works with maps so if you just make sure that your model
returns the map (that you initialized with the right properties in that
model)
then it will work.
By the way what i would do in this case is use just an empty mockup object
for such a thing instead of a map. Because then you also keep the type
safety
and property resolver can get to the type for the textfields (you can
ofcourse set that your self in the code)
johan
On Feb 6, 2008 9:47 PM, Daniel Stoch <da...@gmail.com> wrote:
> Well I forget that PropertyResolver works with maps, so custom models
> probably are not necessary then :). Thanks for tip.
> But in my application I have to use some solutions from other
> application layer (persistance layer), where a special mechanisms to
> track changes in objects are implemented. So I must make general
> interface for this in Wicket.
>
> Daniel
>
> On 2008-02-06, at 21:34, Daniel Stoch wrote:
>
> > 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
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: IPropertyResolver interface for property models
Posted by Daniel Stoch <da...@gmail.com>.
Well I forget that PropertyResolver works with maps, so custom models
probably are not necessary then :). Thanks for tip.
But in my application I have to use some solutions from other
application layer (persistance layer), where a special mechanisms to
track changes in objects are implemented. So I must make general
interface for this in Wicket.
Daniel
On 2008-02-06, at 21:34, Daniel Stoch wrote:
> 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
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: IPropertyResolver interface for property models
Posted by Daniel Stoch <da...@gmail.com>.
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 <da...@gmail.com> wrote:
>> On Feb 6, 2008 3:45 PM, Johan Compagner <jc...@gmail.com> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: IPropertyResolver interface for property models
Posted by Johan Compagner <jc...@gmail.com>.
Why not just return a hashmap as the model object and have besides
that hashmap your real object
On 2/6/08, Daniel Stoch <da...@gmail.com> wrote:
> On Feb 6, 2008 3:45 PM, Johan Compagner <jc...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: IPropertyResolver interface for property models
Posted by Daniel Stoch <da...@gmail.com>.
On Feb 6, 2008 3:45 PM, Johan Compagner <jc...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: IPropertyResolver interface for property models
Posted by Johan Compagner <jc...@gmail.com>.
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 guess you want then to have AbstractPropertyModel to have a
getPropertyResolver method
that you can override and give something else back?
But i still dont get what you really have
What is your model object eventually where a property model works on?
johan
On Feb 6, 2008 1:58 PM, Daniel Stoch <da...@gmail.com> wrote:
> Hi,
>
> I'm developing custom IModel implementation which will be used as a
> model in forms. This model is able to record changes made by a form in
> the editing object (POJO). I do not store this changes directly to the
> base object, but they are stored somwhere inside this model (eg. in a
> Map of properties). Then when I try to read a property value firstly I
> check if this value was modified, if so then value stored inside a
> model is returned, if value was not modified property value from the
> base (original) object is returned. There are some more things in this
> model implementation, but they are not important in context of current
> message.
>
> Now I want to use standard property models to couple my IModel
> implementation with form and form components. But the problem is that
> all of these classes (AbstractPropertyModel, PropertyModel, etc.) use
> PropertyResolver for geting/seting property values, so it is done
> using reflection on object inside a model. These calls to
> PropertyResolver (and PropertyResolverConverter) are "hardcoded" in
> theirs implementations. If I can define my own PropertyResolver then I
> will be able to use these property models with my custom model. Maybe
> we should define IPropertyResolver interface with methods similar to
> these in PropertyResolver and then in "PropertyModel" classes define a
> method getPropertyResolver() which can be overriden in descending
> classes? Of course in the PropertyResolver all methods could not be
> static then. Another possible solution would be to pass
> IPropertyResolver implementation (or better IPropertyResolverProvider
> with getPropertyResolver() method) in property models constructor call
> to allow customization of "property resolving mechanism".
>
> This is a comment to AbstractPropertyModel class:
> * Serves as a base class for different kinds of property models. By
> default, this class uses
> * {@link PropertyResolver} to resolve expressions on the target model
> object. Note that the
> * property resolver by default provides access to private members and
> methods. If guaranteeing
> * encapsulation of the target objects is a big concern, you should
> consider using an alternative
> * implementation.
>
> "By default, this class uses PropertyResolver..." - but there is no
> way to easy change this to some another resolver. The only way is to
> override all of these getObject(), setObject(), getObjectClass(),
> getPropertyField(), getPropertyGetter(), getPropertySetter() methods.
> Ok I know, I can do that and probably I will do, by maybe it is worth
> to think if extracting such interface as IPropertyResolver is a good
> concept?
>
> Best regards,
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>