On Wed, Oct 29, 2008 at 12:02 PM, Maarten Bosteels
<[EMAIL PROTECTED]>wrote:
>
> On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy <
> [EMAIL PROTECTED]> wrote:
>
>> hi maarten
>>
>> > About the null checking, I will see if I can avoid having nested null
>> values
>> > in my proof-of-concept project.
>>
>> thing is the object chain is going to be resolved before it gets
>> passed in - there's nothing you can do about it inside your class :(
>> an eventual null pointer exception would be thrown before your
>> constructor is called.
>
>
> Yes, of course. What I mean is that I would implement my class like this:
>
> public class Customer {
> public final Property<Address> address = new PropertyImpl<Address>() {
>
@Override
public void set(Address value) {
if (value == null) {
throw new NullPointerException("address should not be null");
}
super.set(object);
}
};
> so evaluating customer.address.get().city will never throw a NPE.
>
> When I really need to distingish between customers with or without an
> address, I could add isNull()/setNull() to Address (or maybe even to the
> Property interface itself).
>
> Maarten
>
>
>>
>>
>> francisco
>>
>>
>>
>>
>>
>> >
>> >>
>> >> 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]
>> >> >
>> >> >
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
