It can be done, but the expression languages that I've used don't do it "out of the box", so that would be an issue with using the proxy approach. You'd have to "roll your own"
On Wed, Oct 29, 2008 at 9:14 AM, francisco treacy <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
