it is refactor friendly and you also have code completion (it works with generics)
johan On Wed, Oct 29, 2008 at 12:12 PM, Maarten Bosteels <[EMAIL PROTECTED]>wrote: > On Wed, Oct 29, 2008 at 12:03 PM, Martijn Dashorst < > [EMAIL PROTECTED]> wrote: > > > afiar the proxy based model is null safe. > > > > > Hello Martijn, > > But IIUC it's not refactor-friendly (and no navigation and code > completion), > right ? > > I really hope they add first-class properties (that is, not string-based) > in > java 7 ... > > city = new TextField<String> (customer#address#city); > > Maarten > > > > > > > > On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy > > <[EMAIL PROTECTED]> wrote: > > > 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] > > > > > > > > > > > > > > -- > > Become a Wicket expert, learn from the best: http://wicketinaction.com > > Apache Wicket 1.3.4 is released > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
