or let whatever it is that has dynamic properties also implement Map -igor
On Sat, Nov 13, 2010 at 5:59 AM, James Carman <[email protected]> wrote: > Have you tried using BeanUtils' DynaBeans? BeanUtils can resolve > properties on DynaBeans. I don't know about the default property > resolver in Wicket, though. However, you can always supply your own > which adds functionality. It could even "wrap" the existing one. > > On Sat, Nov 13, 2010 at 7:13 AM, Adrian Wiesmann <[email protected]> wrote: >> Hello list >> >> I am working on filtering tables. To do so I use the FilterToolbar, >> FilterForm, etc. Everything renders perfectly so far. Now I am trying to >> implement my FilterState and run into problems. >> >> Looking into the sourcecode I noticed that the PropertyResolver of Wicket >> tries to find getter and setter methods. My problem with this is, that I >> need some dynamic getter and setter. This is because I work with my own UI >> and data binding engine. I define my UIs in XML and have a renderer render >> my Wicket UI. All UI fields are bound to Cayenne DataObjects via their >> absolute path. Now that is not much of a problem. My model knows how to >> interpret paths like this: >> >> table1.relation2.field3 >> >> But unfortunately the PropertyResolver does not. It only detects specific >> methods but does not support generic ones ( set(String key, Object value), >> get(String key) ). >> >> Now I could generate FilterState-classes for all of my DataObjects and bind >> those to the UI. While this works for UIs binding single tables only, it >> does not work for the example above where a field is bound using a relation >> to another table. >> >> Which brings me to my questions: >> >> - Can I somehow extend the PropertyResolver so that I can add my own >> getter/setter logic for my own FilterState class? >> - Can I somehow have the standard PropertyResolver call dynamic/generic >> setter and getter on my FilterState? >> - Is there another solution to this problem? >> >> Thanks for your help. >> >> Cheers, >> Adrian >> >> --------------------------------------------------------------------- >> 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]
