On Wed, Oct 29, 2008 at 10:54 AM, Wayne Pope <
[EMAIL PROTECTED]> wrote:
> 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?
This would be my domain class, so no extra pojo's needed.
We don't use hibernate for now, but I would like to find out if I can create
a hibernate UserType that can deal with these Property<String> properties.
Did you know that bean-properties has its own ORM implementation:
https://bean-properties.dev.java.net/orm.html ?
I haven't tried it out yet though.
About the null checking, I will see if I can avoid having nested null values
in my proof-of-concept project.
Regards,
Maarten
>
> 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]
> >
> >
>
