Re: Property Models
T is the type parameter for the model object ( http://static.ddpoker.com/javadoc/wicket/1.4-m1/org/apache/wicket/model/IModel.html), if you are creating an PropertyModel to retrieve and access an String property, so String is the correct type parameter for the PropertyModel... On Tue, Sep 8, 2009 at 2:13 AM, Douglas Ferguson doug...@douglasferguson.us wrote: If I have a have this: CompoundPropertyModel(Person) PropertyModel(Person, name); Would this be accurate? CompoundPropertyModelPerson PropertyModelString -assuming name is a string - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Property Models
If I have a have this: CompoundPropertyModel(Person) PropertyModel(Person, name); Would this be accurate? CompoundPropertyModelPerson PropertyModelString -assuming name is a string - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Forcing property models to update
Hmm, this requires a bit low level Java understanding (Wicket doesn't
have anything to do with it.
The underlying mechanism is the same as doing this:
public void foo2bar(String a) {
a = bar;
}
String b = foo;
System.out.println(b is now: + b);
foo2bar(b);
System.out.println(b is now: + b);
What do you expect here? [1]
Now consider this:
public class Foo2Bar {
private String text;
public Foo2Bar(String t) {
this.text = t;
}
public void setText(String t) {
this.text = t;
}
public toString() {
return text;
}
}
String b = foo;
Foo2Bar f2b = new Foo2Bar(b);
System.out.println(f2b is now: + f2b);
b = bar;
System.out.println(f2b is now: + f2b);
What do you expect now? [2]
Java copies references to objects. When you modify the original
reference to point to another object, the copy doesn't get notified of
this change. THis is what is happening in your property models: you
give it a reference to a person, which is copied (the reference). Next
you modify the reference, but don't provide a way to notify the
property model that it should point to another person.
So to fix the second example: we need to notify our f2b instance that
the reference has changed, by calling setText
Martijn
[1] foo and foo
[2] f2b is now: foo and f2b is now: foo
On Tue, Oct 28, 2008 at 10:35 PM, walnutmon [EMAIL PROTECTED] wrote:
I did as you said, and have the unit tests, and read the wiki on chaining
models... something still isn't clicking though. BTW, I have Wicket in
action and it is fantastic, perhaps there is still something elduing me
though... I still can't wrap my head around why that property model doesn't
update in the first case you show me. If the property model is calling that
object, and doing a get description each time it's called it's own
getObject() method, why doesn't changing the reference externally work?
If you simply point me to a page number and tell me to read until I
understand, I would be greatful!
Thanks again!
Justin
Martijn Dashorst wrote:
No defensive copying happening. Just your plain old references
updating. Read the models page on the wiki about chaining models.
Put this in a unit test case:
State s = new State();
s.setDescription(I haven't read Wicket in Action but hear it helps
solve these questions);
PropertyModel pm = new PropertyModel(s, description);
assertEquals(I haven't read Wicket in Action but hear it helps solve
these questions, pm.getObject());
s = new State();
s.setDescription(I'll buy Wicket in Action, just because I now get
why my property model doesn't know this new state yet.);
assertEquals(I'll buy Wicket in Action, just because I now get why my
property model doesn't know this new state yet., pm.getObject());
This is basically what you are doing in your panel.
but if you did:
State s = new State(Foo);
Model m = new Model();
m.setObject(s);
PropertyModel pm = new PropertyModel(m, description);
assertEquals(Foo, pm.getObject());
and now for the coup de grace:
s = new State(Bar);
m.setObject(s);
assertEquals(Bar, pm.getObject());
Martijn
On Fri, Oct 24, 2008 at 3:57 PM, walnutmon [EMAIL PROTECTED]
wrote:
I have two panels, a view panel where you can look for news and an edit
panel. The edit panel has a reference to a news object and all of it's
form elements have property models that use that object.
When I pass a news object into the panel on creation all of the form
elements fill as expected. However, if I set that object through a
setter
in the panel class, the elements do not update. My theory (which may be
wrong) is that the property model makes a defensive copy and therefore is
not linked to the object in the class. If this is true, can I resend the
object to the property model?
If that's not true, any insight as to what I may be doing wrong?
--
View this message in context:
http://www.nabble.com/Forcing-property-models-to-update-tp20150693p20150693.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Forcing-property-models-to-update-tp20150693p20216529.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from the best: http
Re: Forcing property models to update
I did as you said, and have the unit tests, and read the wiki on chaining models... something still isn't clicking though. BTW, I have Wicket in action and it is fantastic, perhaps there is still something elduing me though... I still can't wrap my head around why that property model doesn't update in the first case you show me. If the property model is calling that object, and doing a get description each time it's called it's own getObject() method, why doesn't changing the reference externally work? If you simply point me to a page number and tell me to read until I understand, I would be greatful! Thanks again! Justin Martijn Dashorst wrote: No defensive copying happening. Just your plain old references updating. Read the models page on the wiki about chaining models. Put this in a unit test case: State s = new State(); s.setDescription(I haven't read Wicket in Action but hear it helps solve these questions); PropertyModel pm = new PropertyModel(s, description); assertEquals(I haven't read Wicket in Action but hear it helps solve these questions, pm.getObject()); s = new State(); s.setDescription(I'll buy Wicket in Action, just because I now get why my property model doesn't know this new state yet.); assertEquals(I'll buy Wicket in Action, just because I now get why my property model doesn't know this new state yet., pm.getObject()); This is basically what you are doing in your panel. but if you did: State s = new State(Foo); Model m = new Model(); m.setObject(s); PropertyModel pm = new PropertyModel(m, description); assertEquals(Foo, pm.getObject()); and now for the coup de grace: s = new State(Bar); m.setObject(s); assertEquals(Bar, pm.getObject()); Martijn On Fri, Oct 24, 2008 at 3:57 PM, walnutmon [EMAIL PROTECTED] wrote: I have two panels, a view panel where you can look for news and an edit panel. The edit panel has a reference to a news object and all of it's form elements have property models that use that object. When I pass a news object into the panel on creation all of the form elements fill as expected. However, if I set that object through a setter in the panel class, the elements do not update. My theory (which may be wrong) is that the property model makes a defensive copy and therefore is not linked to the object in the class. If this is true, can I resend the object to the property model? If that's not true, any insight as to what I may be doing wrong? -- View this message in context: http://www.nabble.com/Forcing-property-models-to-update-tp20150693p20150693.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Forcing-property-models-to-update-tp20150693p20216529.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Forcing property models to update
I have two panels, a view panel where you can look for news and an edit panel. The edit panel has a reference to a news object and all of it's form elements have property models that use that object. When I pass a news object into the panel on creation all of the form elements fill as expected. However, if I set that object through a setter in the panel class, the elements do not update. My theory (which may be wrong) is that the property model makes a defensive copy and therefore is not linked to the object in the class. If this is true, can I resend the object to the property model? If that's not true, any insight as to what I may be doing wrong? -- View this message in context: http://www.nabble.com/Forcing-property-models-to-update-tp20150693p20150693.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Forcing property models to update
No defensive copying happening. Just your plain old references updating. Read the models page on the wiki about chaining models. Put this in a unit test case: State s = new State(); s.setDescription(I haven't read Wicket in Action but hear it helps solve these questions); PropertyModel pm = new PropertyModel(s, description); assertEquals(I haven't read Wicket in Action but hear it helps solve these questions, pm.getObject()); s = new State(); s.setDescription(I'll buy Wicket in Action, just because I now get why my property model doesn't know this new state yet.); assertEquals(I'll buy Wicket in Action, just because I now get why my property model doesn't know this new state yet., pm.getObject()); This is basically what you are doing in your panel. but if you did: State s = new State(Foo); Model m = new Model(); m.setObject(s); PropertyModel pm = new PropertyModel(m, description); assertEquals(Foo, pm.getObject()); and now for the coup de grace: s = new State(Bar); m.setObject(s); assertEquals(Bar, pm.getObject()); Martijn On Fri, Oct 24, 2008 at 3:57 PM, walnutmon [EMAIL PROTECTED] wrote: I have two panels, a view panel where you can look for news and an edit panel. The edit panel has a reference to a news object and all of it's form elements have property models that use that object. When I pass a news object into the panel on creation all of the form elements fill as expected. However, if I set that object through a setter in the panel class, the elements do not update. My theory (which may be wrong) is that the property model makes a defensive copy and therefore is not linked to the object in the class. If this is true, can I resend the object to the property model? If that's not true, any insight as to what I may be doing wrong? -- View this message in context: http://www.nabble.com/Forcing-property-models-to-update-tp20150693p20150693.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Forcing property models to update
Martijn is the guy that sprays buttered popcorn smell in the theatre vents for that extra little bit of subliminal selling power. :) Seriously, though - buy the book - it's worth it's weight in gold. -- Jeremy Thomerson http://www.wickettraining.com On Fri, Oct 24, 2008 at 9:18 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: No defensive copying happening. Just your plain old references updating. Read the models page on the wiki about chaining models. Put this in a unit test case: State s = new State(); s.setDescription(I haven't read Wicket in Action but hear it helps solve these questions); PropertyModel pm = new PropertyModel(s, description); assertEquals(I haven't read Wicket in Action but hear it helps solve these questions, pm.getObject()); s = new State(); s.setDescription(I'll buy Wicket in Action, just because I now get why my property model doesn't know this new state yet.); assertEquals(I'll buy Wicket in Action, just because I now get why my property model doesn't know this new state yet., pm.getObject()); This is basically what you are doing in your panel. but if you did: State s = new State(Foo); Model m = new Model(); m.setObject(s); PropertyModel pm = new PropertyModel(m, description); assertEquals(Foo, pm.getObject()); and now for the coup de grace: s = new State(Bar); m.setObject(s); assertEquals(Bar, pm.getObject()); Martijn On Fri, Oct 24, 2008 at 3:57 PM, walnutmon [EMAIL PROTECTED] wrote: I have two panels, a view panel where you can look for news and an edit panel. The edit panel has a reference to a news object and all of it's form elements have property models that use that object. When I pass a news object into the panel on creation all of the form elements fill as expected. However, if I set that object through a setter in the panel class, the elements do not update. My theory (which may be wrong) is that the property model makes a defensive copy and therefore is not linked to the object in the class. If this is true, can I resend the object to the property model? If that's not true, any insight as to what I may be doing wrong? -- View this message in context: http://www.nabble.com/Forcing-property-models-to-update-tp20150693p20150693.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Forcing property models to update
m popcorn! -igor On Fri, Oct 24, 2008 at 7:47 AM, Jeremy Thomerson [EMAIL PROTECTED] wrote: Martijn is the guy that sprays buttered popcorn smell in the theatre vents for that extra little bit of subliminal selling power. :) Seriously, though - buy the book - it's worth it's weight in gold. -- Jeremy Thomerson http://www.wickettraining.com On Fri, Oct 24, 2008 at 9:18 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: No defensive copying happening. Just your plain old references updating. Read the models page on the wiki about chaining models. Put this in a unit test case: State s = new State(); s.setDescription(I haven't read Wicket in Action but hear it helps solve these questions); PropertyModel pm = new PropertyModel(s, description); assertEquals(I haven't read Wicket in Action but hear it helps solve these questions, pm.getObject()); s = new State(); s.setDescription(I'll buy Wicket in Action, just because I now get why my property model doesn't know this new state yet.); assertEquals(I'll buy Wicket in Action, just because I now get why my property model doesn't know this new state yet., pm.getObject()); This is basically what you are doing in your panel. but if you did: State s = new State(Foo); Model m = new Model(); m.setObject(s); PropertyModel pm = new PropertyModel(m, description); assertEquals(Foo, pm.getObject()); and now for the coup de grace: s = new State(Bar); m.setObject(s); assertEquals(Bar, pm.getObject()); Martijn On Fri, Oct 24, 2008 at 3:57 PM, walnutmon [EMAIL PROTECTED] wrote: I have two panels, a view panel where you can look for news and an edit panel. The edit panel has a reference to a news object and all of it's form elements have property models that use that object. When I pass a news object into the panel on creation all of the form elements fill as expected. However, if I set that object through a setter in the panel class, the elements do not update. My theory (which may be wrong) is that the property model makes a defensive copy and therefore is not linked to the object in the class. If this is true, can I resend the object to the property model? If that's not true, any insight as to what I may be doing wrong? -- View this message in context: http://www.nabble.com/Forcing-property-models-to-update-tp20150693p20150693.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - 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]
Re: IPropertyResolver interface for property models
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 * [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IPropertyResolver interface for property models
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 [EMAIL PROTECTED] 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 * [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
RE: IPropertyResolver interface for property models
g.. 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: 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:[EMAIL PROTECTED]
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
[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]
Re: IPropertyResolver interface for property models
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: IPropertyResolver interface for property models
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]
Re: IPropertyResolver interface for property models
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]
Re: IPropertyResolver interface for property models
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
