hi, > One problem I see with this approach is when you need null-checking > for nested properties: > eg: new TextField<String>("city", customer.address.getObject().city );
exactly, that is *the* problem otherwise we could have new AlternativeCompoundPropertyModel(customer.getAddress().getCity()); with this class decomposing the object chain into an el-style expression: customer.address.city which will be the wicket:id ... *but*, this can easily lose synchronization with the markup. another web framework called warp-widgets uses compile-time checking of expressions in html files with mvel. perhaps this points us in the right direction... we were also thinking of something like a "compile time annotation" (with logic) such as java's @SuppressWarnings , but not sure if it'll work though. any thoughts on this? francisco > > Let me know what you think about it. > > Maarten > > >> Thanks for any update if anyone knows anything! >> Wayne >> >> >> >> >> >> Johan Compagner wrote: >>> >>> no i really dont like that >>> then everywhere there code they need to do that, that is not an option. >>> and they have to program themselfs agains the proxy api. I dont want that >>> developers also have the learn/do that >>> This is something commons-proxy needs to do >>> >>> On Sat, Mar 8, 2008 at 3:29 PM, James Carman <[EMAIL PROTECTED]> >>> wrote: >>> >>>> Couldn't you also do: >>>> >>>> ProxyFactory pf = ...; >>>> new SharedPropertyModel<Customer>(pf, customer); >>>> >>>> So, the client tells you what proxy factory implementation to use. >>>> >>>> On 3/8/08, James Carman <[EMAIL PROTECTED]> wrote: >>>> > I see the JIRA, I'll go ahead and start the discussion on the dev list. >>>> > >>>> > >>>> > On 3/8/08, James Carman <[EMAIL PROTECTED]> wrote: >>>> > > On 3/8/08, Johan Compagner <[EMAIL PROTECTED]> wrote: >>>> > > >>>> > > > for wicket this is a feature it really should have >>>> > > > now it defeats the purpose i have to make a decission in wicket >>>> which >>>> > > > factory i use >>>> > > > Then i can just as well directly compile against cglib. >>>> > > > I cant make the api that way that the developer has to give that >>>> factory to >>>> > > > use. That would be completely horrible, >>>> > > > >>>> > > >>>> > > >>>> > > You could always implement your own brand of discovery for your >>>> > > project (perhaps by using the service discovery feature built into >>>> the >>>> > > jdk). >>>> > > >>>> > > I like the idea of splitting it (and doing it the slf4j way rather >>>> > > than the JCL way). I have actually suggested that we start an >>>> > > exploratory branch of JCL to make it work more like slf4j (we've >>>> been >>>> > > talking about this since 2005). Anyway, if you file a JIRA issue, >>>> > > I'll make sure we have a discussion with the other devs. For your >>>> > > immediate purposes, commons-discovery is available also. >>>> > > >>>> > >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.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] >> >> > > --------------------------------------------------------------------- > 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]