i agree - that's why i think it would be difficult to avoid an eventual NPE in something like customer.getAddress().getCity().getBlabla() in that case
On Wed, Oct 29, 2008 at 1:09 PM, James Carman <[EMAIL PROTECTED]> wrote: > You shouldn't muddy up your "domain" with view-specific logic (the > IModel interface). > > On Wed, Oct 29, 2008 at 5:42 AM, Maarten Bosteels > <[EMAIL PROTECTED]> wrote: >> On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <[EMAIL PROTECTED]> wrote: >>> >>> Hi, >>> >>> Francisco and I here where discussing whether we could figure a way of >>> having some form of static/compile time checking on our >>> (Compound)PropertyModels, as I'm a bit concerned long term about some nasty >>> runtime bugs that might slip through the testing coverage. Francisco found >>> this thread - I'm wondering what the status is? I had a look at: >>> https://issues.apache.org/jira/browse/WICKET-1327 >>> >>> and there doesn't look like any activity since Feb. Anyone been using this >>> or come up with a different solution? >>> >>> Ideally I think it would be just great if we had an eclipse plugin that >>> could just check for this (a bit like checkstyle or something) but a runtime >>> solution as proposed above seems really smart as well. However I'd rather >>> keep is 100% java (ie not cglib) if possible. >> >> Hello, >> >> If you want something 100% java you could copde your domain models like this: >> >> public class Customer implements Serializable { >> public final IModel<String> firstName = new Model<String>(); >> public final IModel<String> lastName = new Model<String>(); >> } >> >> and use it like this: >> >> form.add(new TextField<String>("firstName", customer.firstName)); >> form.add(new TextField<String>("lastName", customer.lastName)); >> >> => no need to generate ugly getters/setters for all your properties >> => pure java >> => refactoring-safe >> => navigation + code-completion from IDE >> => you can still override setObject() and/or setObject() when needed >> >> In this example I have used wicket's IModel and Model but you could >> also use Property<String> from https://bean-properties.dev.java.net/ >> which has a lot of other benefits (a pity that the project is stalled a bit). >> >> Note that I haven't used this extensively but I sure do want to test >> it out in the near future.. >> >> 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 ); >> >> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
