CompoundModel based on proxies

[Wayne Pope]

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.

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 <[e-mail]>
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 <[e-mail]> wrote:
> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
> >
> >
> >  On 3/8/08, James Carman <[e-mail]> wrote:
> >  > On 3/8/08, Johan Compagner <[e-mail]> 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: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[Nino.Martinez]

Yeah, I must say im looking forward to getting Wicket-1327 a reality too..

Wayne Pope 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.
>
> 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 <james@...>
>> 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 <james@...> wrote:
>>>      
>>>> I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>>>
>>>>
>>>>  On 3/8/08, James Carman <james@...> wrote:
>>>>  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>      
>>    
>
>  

--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
[phone]


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Johan Compagner]

wicket 1.5

first 1.4 has to be released

On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@...>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.
>
> 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 <james@...
> >
> > 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 <james@...> wrote:
> >> > I see the JIRA, I'll go ahead and start the discussion on the dev
> list.
> >> >
> >> >
> >> >  On 3/8/08, James Carman <james@...> wrote:
> >> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> >
>
> --
> 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: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Maarten Bosteels]

On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@...> 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 <james@...>
>> 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 <james@...> wrote:
>>> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>> >
>>> >
>>> >  On 3/8/08, James Carman <james@...> wrote:
>>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>>
>
> --
> 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: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Wayne Pope-2]

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
<mbosteels.dns@...>wrote:

> On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@...>
> 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 <
> james@...>
> >> 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 <james@...> wrote:
> >>> > I see the JIRA, I'll go ahead and start the discussion on the dev
> list.
> >>> >
> >>> >
> >>> >  On 3/8/08, James Carman <james@...> wrote:
> >>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
> >>> For additional commands, e-mail: users-help@...
> >>>
> >>>
> >>
> >>
> >
> > --
> > 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: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Wayne Pope-2]

Hi Johan,

we're now maigrating to 1.4 M3 - do you have any idea roughly when the
release proper of 1.4 would be?
thanks
Wayne

On Wed, Oct 29, 2008 at 10:34 AM, Johan Compagner <jcompagner@...>wrote:

> wicket 1.5
>
> first 1.4 has to be released
>
> On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@...
> >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.
> >
> > 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 <
> james@...
> > >
> > > 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 <james@...> wrote:
> > >> > I see the JIRA, I'll go ahead and start the discussion on the dev
> > list.
> > >> >
> > >> >
> > >> >  On 3/8/08, James Carman <james@...> wrote:
> > >> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
> > >> For additional commands, e-mail: users-help@...
> > >>
> > >>
> > >
> > >
> >
> > --
> > 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: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>

[francisco treacy-2]

hi,

> 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 );

exactly, that is *the* problem

otherwise we could have
 new AlternativeCompoundPropertyModel(customer.getAddress().getCity());
with this class decomposing the object chain into an el-style
expression: customer.address.city which will be the wicket:id ...
*but*, this can easily lose synchronization with the markup.

another web framework called warp-widgets uses compile-time checking
of expressions in html files with mvel. perhaps this points us in the
right direction...

we were also thinking of something like a "compile time annotation"
(with logic) such as java's @SuppressWarnings , but not sure if it'll
work though.

any thoughts on this?

francisco

>
> 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 <james@...>
>>> 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 <james@...> wrote:
>>>> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>>> >
>>>> >
>>>> >  On 3/8/08, James Carman <james@...> wrote:
>>>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>>
>>
>> --
>> 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: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Maarten Bosteels]

On Wed, Oct 29, 2008 at 10:54 AM, Wayne Pope <
waynemailinglists@...> 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
> <mbosteels.dns@...>wrote:
>
> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@...
> >
> > 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 <
> > james@...>
> > >> 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 <james@...> wrote:
> > >>> > I see the JIRA, I'll go ahead and start the discussion on the dev
> > list.
> > >>> >
> > >>> >
> > >>> >  On 3/8/08, James Carman <james@...> wrote:
> > >>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
> > >>> For additional commands, e-mail: users-help@...
> > >>>
> > >>>
> > >>
> > >>
> > >
> > > --
> > > 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: users-unsubscribe@...
> > > For additional commands, e-mail: users-help@...
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>

[francisco treacy-2]

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.

francisco

>
>>
>> On Wed, Oct 29, 2008 at 10:42 AM, Maarten Bosteels
>> <mbosteels.dns@...>wrote:
>>
>> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@...
>> >
>> > 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 <
>> > james@...>
>> > >> 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 <james@...> wrote:
>> > >>> > I see the JIRA, I'll go ahead and start the discussion on the dev
>> > list.
>> > >>> >
>> > >>> >
>> > >>> >  On 3/8/08, James Carman <james@...> wrote:
>> > >>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
>> > >>> For additional commands, e-mail: users-help@...
>> > >>>
>> > >>>
>> > >>
>> > >>
>> > >
>> > > --
>> > > 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: users-unsubscribe@...
>> > > For additional commands, e-mail: users-help@...
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>> >
>> >
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Maarten Bosteels]

On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy <
francisco.treacy@...> 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>();
}

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
> >> <mbosteels.dns@...>wrote:
> >>
> >> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <
> waynemailinglists@...
> >> >
> >> > 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 <
> >> > james@...>
> >> > >> 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 <james@...> wrote:
> >> > >>> > I see the JIRA, I'll go ahead and start the discussion on the
> dev
> >> > list.
> >> > >>> >
> >> > >>> >
> >> > >>> >  On 3/8/08, James Carman <james@...> wrote:
> >> > >>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
> >> > >>> For additional commands, e-mail: users-help@...
> >> > >>>
> >> > >>>
> >> > >>
> >> > >>
> >> > >
> >> > > --
> >> > > 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: users-unsubscribe@...
> >> > > For additional commands, e-mail: users-help@...
> >> > >
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@...
> >> > For additional commands, e-mail: users-help@...
> >> >
> >> >
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Martijn Dashorst]

afiar the proxy based model is null safe.

Martijn

On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy
<francisco.treacy@...> 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.
>
> francisco
>
>
>
>
>
>>
>>>
>>> On Wed, Oct 29, 2008 at 10:42 AM, Maarten Bosteels
>>> <mbosteels.dns@...>wrote:
>>>
>>> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@...
>>> >
>>> > 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 <
>>> > james@...>
>>> > >> 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 <james@...> wrote:
>>> > >>> > I see the JIRA, I'll go ahead and start the discussion on the dev
>>> > list.
>>> > >>> >
>>> > >>> >
>>> > >>> >  On 3/8/08, James Carman <james@...> wrote:
>>> > >>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
>>> > >>> For additional commands, e-mail: users-help@...
>>> > >>>
>>> > >>>
>>> > >>
>>> > >>
>>> > >
>>> > > --
>>> > > 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: users-unsubscribe@...
>>> > > For additional commands, e-mail: users-help@...
>>> > >
>>> > >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@...
>>> > For additional commands, e-mail: users-help@...
>>> >
>>> >
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Maarten Bosteels]

On Wed, Oct 29, 2008 at 12:02 PM, Maarten Bosteels
<mbosteels.dns@...>wrote:

>
> On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy <
> francisco.treacy@...> 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
>> >> <mbosteels.dns@...>wrote:
>> >>
>> >> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <
>> waynemailinglists@...
>> >> >
>> >> > 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 <
>> >> > james@...>
>> >> > >> 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 <james@...> wrote:
>> >> > >>> > I see the JIRA, I'll go ahead and start the discussion on the
>> dev
>> >> > list.
>> >> > >>> >
>> >> > >>> >
>> >> > >>> >  On 3/8/08, James Carman <james@...> wrote:
>> >> > >>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
>> >> > >>> For additional commands, e-mail: users-help@...
>> >> > >>>
>> >> > >>>
>> >> > >>
>> >> > >>
>> >> > >
>> >> > > --
>> >> > > 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: users-unsubscribe@...
>> >> > > For additional commands, e-mail: users-help@...
>> >> > >
>> >> > >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@...
>> >> > For additional commands, e-mail: users-help@...
>> >> >
>> >> >
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>

[Maarten Bosteels]

On Wed, Oct 29, 2008 at 12:03 PM, Martijn Dashorst <
martijn.dashorst@...> wrote:

> afiar the proxy based model is null safe.
>
>
Hello Martijn,

But IIUC it's not refactor-friendly (and no navigation and code completion),
right ?

I really hope they add first-class properties (that is, not string-based) in
java 7 ...

city = new TextField<String> (customer#address#city);

Maarten

>
>
> On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy
> <francisco.treacy@...> 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.
> >
> > francisco
> >
> >
> >
> >
> >
> >>
> >>>
> >>> On Wed, Oct 29, 2008 at 10:42 AM, Maarten Bosteels
> >>> <mbosteels.dns@...>wrote:
> >>>
> >>> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <
> waynemailinglists@...
> >>> >
> >>> > 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 <
> >>> > james@...>
> >>> > >> 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 <james@...> wrote:
> >>> > >>> > I see the JIRA, I'll go ahead and start the discussion on the
> dev
> >>> > list.
> >>> > >>> >
> >>> > >>> >
> >>> > >>> >  On 3/8/08, James Carman <james@...> wrote:
> >>> > >>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
> >>> > >>> For additional commands, e-mail: users-help@...
> >>> > >>>
> >>> > >>>
> >>> > >>
> >>> > >>
> >>> > >
> >>> > > --
> >>> > > 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: users-unsubscribe@...
> >>> > > For additional commands, e-mail: users-help@...
> >>> > >
> >>> > >
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: users-unsubscribe@...
> >>> > For additional commands, e-mail: users-help@...
> >>> >
> >>> >
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.4 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Johan Compagner]

it is refactor friendly and you also have code completion
(it works with generics)

johan


On Wed, Oct 29, 2008 at 12:12 PM, Maarten Bosteels
<mbosteels.dns@...>wrote:

> On Wed, Oct 29, 2008 at 12:03 PM, Martijn Dashorst <
> martijn.dashorst@...> wrote:
>
> > afiar the proxy based model is null safe.
> >
> >
> Hello Martijn,
>
> But IIUC it's not refactor-friendly (and no navigation and code
> completion),
> right ?
>
> I really hope they add first-class properties (that is, not string-based)
> in
> java 7 ...
>
> city = new TextField<String> (customer#address#city);
>
> Maarten
>
>
> >
> >
> > On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy
> > <francisco.treacy@...> 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.
> > >
> > > francisco
> > >
> > >
> > >
> > >
> > >
> > >>
> > >>>
> > >>> On Wed, Oct 29, 2008 at 10:42 AM, Maarten Bosteels
> > >>> <mbosteels.dns@...>wrote:
> > >>>
> > >>> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <
> > waynemailinglists@...
> > >>> >
> > >>> > 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 <
> > >>> > james@...>
> > >>> > >> 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 <james@...> wrote:
> > >>> > >>> > I see the JIRA, I'll go ahead and start the discussion on the
> > dev
> > >>> > list.
> > >>> > >>> >
> > >>> > >>> >
> > >>> > >>> >  On 3/8/08, James Carman <james@...> wrote:
> > >>> > >>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
> > >>> > >>> For additional commands, e-mail: users-help@...
> > >>> > >>>
> > >>> > >>>
> > >>> > >>
> > >>> > >>
> > >>> > >
> > >>> > > --
> > >>> > > 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: users-unsubscribe@...
> > >>> > > For additional commands, e-mail: users-help@...
> > >>> > >
> > >>> > >
> > >>> >
> > >>> >
> ---------------------------------------------------------------------
> > >>> > To unsubscribe, e-mail: users-unsubscribe@...
> > >>> > For additional commands, e-mail: users-help@...
> > >>> >
> > >>> >
> > >>>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@...
> > > For additional commands, e-mail: users-help@...
> > >
> > >
> >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> > Apache Wicket 1.3.4 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>

[jwcarman]

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
<mbosteels.dns@...> wrote:

> On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@...> 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 <james@...>
>>> 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 <james@...> wrote:
>>>> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>>> >
>>>> >
>>>> >  On 3/8/08, James Carman <james@...> wrote:
>>>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>>
>>
>> --
>> 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: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[francisco treacy-2]

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
<james@...> 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
> <mbosteels.dns@...> wrote:
>> On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@...> 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 <james@...>
>>>> 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 <james@...> wrote:
>>>>> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>>>> >
>>>>> >
>>>>> >  On 3/8/08, James Carman <james@...> wrote:
>>>>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> 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: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jwcarman]

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
<francisco.treacy@...> 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
> <james@...> 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
>> <mbosteels.dns@...> wrote:
>>> On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@...> 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 <james@...>
>>>>> 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 <james@...> wrote:
>>>>>> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>>>>> >
>>>>>> >
>>>>>> >  On 3/8/08, James Carman <james@...> wrote:
>>>>>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Maarten Bosteels]

On Wed, Oct 29, 2008 at 1:09 PM, James Carman <james@...>wrote:

> You shouldn't muddy up your "domain" with view-specific logic (the
> IModel interface).


In my example I just used IModel<T> instead of Property<T> because everybody
knows IModel.

Have a look at https://bean-properties.dev.java.net/
It's certainly *not* view-specific logic.  It's a very simple idea, and way
more elegant than ugly setters and getters.

But I will have a look at the proxy approach as well.

regards
Maarten

>
> On Wed, Oct 29, 2008 at 5:42 AM, Maarten Bosteels
> <mbosteels.dns@...> wrote:
> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@...>
> 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 <
> james@...>
> >>> 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 <james@...> wrote:
> >>>> > I see the JIRA, I'll go ahead and start the discussion on the dev
> list.
> >>>> >
> >>>> >
> >>>> >  On 3/8/08, James Carman <james@...> wrote:
> >>>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
> >>>> For additional commands, e-mail: users-help@...
> >>>>
> >>>>
> >>>
> >>>
> >>
> >> --
> >> 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: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[jwcarman]

The IModel interface, if you're talking about the one from Wicket, is
a view-specific interface (it comes with a view layer library).

On Wed, Oct 29, 2008 at 9:20 AM, Maarten Bosteels
<mbosteels.dns@...> wrote:

> On Wed, Oct 29, 2008 at 1:09 PM, James Carman <james@...>wrote:
>
>> You shouldn't muddy up your "domain" with view-specific logic (the
>> IModel interface).
>
>
> In my example I just used IModel<T> instead of Property<T> because everybody
> knows IModel.
>
> Have a look at https://bean-properties.dev.java.net/
> It's certainly *not* view-specific logic.  It's a very simple idea, and way
> more elegant than ugly setters and getters.
>
> But I will have a look at the proxy approach as well.
>
> regards
> Maarten
>
>
>>
>> On Wed, Oct 29, 2008 at 5:42 AM, Maarten Bosteels
>> <mbosteels.dns@...> wrote:
>> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@...>
>> 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 <
>> james@...>
>> >>> 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 <james@...> wrote:
>> >>>> > I see the JIRA, I'll go ahead and start the discussion on the dev
>> list.
>> >>>> >
>> >>>> >
>> >>>> >  On 3/8/08, James Carman <james@...> wrote:
>> >>>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
>> >>>> For additional commands, e-mail: users-help@...
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> 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: users-unsubscribe@...
>> >> For additional commands, e-mail: users-help@...
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Maarten Bosteels]

On Wed, Oct 29, 2008 at 2:24 PM, James Carman <james@...>wrote:

> The IModel interface, if you're talking about the one from Wicket, is
> a view-specific interface (it comes with a view layer library).


James,

Have you actually read what I wrote ?

Maarten

>
>
> On Wed, Oct 29, 2008 at 9:20 AM, Maarten Bosteels
> <mbosteels.dns@...> wrote:
> > On Wed, Oct 29, 2008 at 1:09 PM, James Carman <
> james@...>wrote:
> >
> >> You shouldn't muddy up your "domain" with view-specific logic (the
> >> IModel interface).
> >
> >
> > In my example I just used IModel<T> instead of Property<T> because
> everybody
> > knows IModel.
> >
> > Have a look at https://bean-properties.dev.java.net/
> > It's certainly *not* view-specific logic.  It's a very simple idea, and
> way
> > more elegant than ugly setters and getters.
> >
> > But I will have a look at the proxy approach as well.
> >
> > regards
> > Maarten
> >
> >
> >>
> >> On Wed, Oct 29, 2008 at 5:42 AM, Maarten Bosteels
> >> <mbosteels.dns@...> wrote:
> >> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <
> waynemailinglists@...>
> >> 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 <
> >> james@...>
> >> >>> 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 <james@...> wrote:
> >> >>>> > I see the JIRA, I'll go ahead and start the discussion on the dev
> >> list.
> >> >>>> >
> >> >>>> >
> >> >>>> >  On 3/8/08, James Carman <james@...> wrote:
> >> >>>> >  > On 3/8/08, Johan Compagner <jcompagner@...> 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: users-unsubscribe@...
> >> >>>> For additional commands, e-mail: users-help@...
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>
> >> >> --
> >> >> 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: users-unsubscribe@...
> >> >> For additional commands, e-mail: users-help@...
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@...
> >> > For additional commands, e-mail: users-help@...
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>