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] > >
