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]
