Hi Maarten
interesting idea thanks. I think the major issue is the null pointer
checking.
for your:
public class Customer implements Serializable {
public final IModel<String> firstName = new Model<String>();
public final IModel<String> lastName = new Model<String>();
}
do you wrap this around you (hibernate/other) pojo's or are this additional
fields?
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]
>
>
