hi maarten > About the null checking, I will see if I can avoid having nested null values > in my proof-of-concept project.
thing is the object chain is going to be resolved before it gets passed in - there's nothing you can do about it inside your class :( an eventual null pointer exception would be thrown before your constructor is called. francisco > >> >> On Wed, Oct 29, 2008 at 10: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]
