Sorry, but I am on many mailing lists as part of my open source involvement. I apologize if I breezed over some of what you wrote. I see now where you said you could use the Property API from that other project, which is what I would suggest as opposed to IModel from the Wicket library if you're going to use it in your "domain." I have a bad habit of half-reading these emails just so I can keep up with the volume of traffic from all of the lists. :)
On Wed, Oct 29, 2008 at 9:29 AM, Maarten Bosteels <[EMAIL PROTECTED]> wrote: > On Wed, Oct 29, 2008 at 2:24 PM, James Carman <[EMAIL PROTECTED]>wrote: > >> The IModel interface, if you're talking about the one from Wicket, is >> a view-specific interface (it comes with a view layer library). > > > James, > > Have you actually read what I wrote ? > > Maarten > > >> >> >> On Wed, Oct 29, 2008 at 9:20 AM, Maarten Bosteels >> <[EMAIL PROTECTED]> wrote: >> > 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). >> > >> > >> > In my example I just used IModel<T> instead of Property<T> because >> everybody >> > knows IModel. >> > >> > Have a look at https://bean-properties.dev.java.net/ >> > It's certainly *not* view-specific logic. It's a very simple idea, and >> way >> > more elegant than ugly setters and getters. >> > >> > But I will have a look at the proxy approach as well. >> > >> > regards >> > Maarten >> > >> > >> >> >> >> 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
