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
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
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 in
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
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 getEdite
[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:
>
&g
homas
> -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]&
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 AbstractPropertyM
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 ge
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 propert
10 matches
Mail list logo
