You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Wayne Pope <wa...@gmail.com> on 2008/10/29 08:35:14 UTC
Re: CompoundModel based on proxies
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 <ja...@carmanconsulting.com>
> 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 <ja...@carmanconsulting.com> wrote:
>> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
>> >
>> >
>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
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@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: CompoundModel based on proxies
Posted by Maarten Bosteels <mb...@gmail.com>.
On Wed, Oct 29, 2008 at 12:02 PM, Maarten Bosteels
<mb...@gmail.com>wrote:
>
> On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy <
> francisco.treacy@gmail.com> 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
>> >> <mb...@gmail.com>wrote:
>> >>
>> >> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <
>> waynemailinglists@gmail.com
>> >> >
>> >> > 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@carmanconsulting.com>
>> >> > >> 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 <ja...@carmanconsulting.com> wrote:
>> >> > >>> > I see the JIRA, I'll go ahead and start the discussion on the
>> dev
>> >> > list.
>> >> > >>> >
>> >> > >>> >
>> >> > >>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
>> >> > >>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
>> >> > >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> > >>>
>> >> > >>>
>> >> > >>
>> >> > >>
>> >> > >
>> >> > > --
>> >> > > 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@wicket.apache.org
>> >> > > For additional commands, e-mail: users-help@wicket.apache.org
>> >> > >
>> >> > >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: CompoundModel based on proxies
Posted by Maarten Bosteels <mb...@gmail.com>.
On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy <
francisco.treacy@gmail.com> 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
> >> <mb...@gmail.com>wrote:
> >>
> >> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <
> waynemailinglists@gmail.com
> >> >
> >> > 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@carmanconsulting.com>
> >> > >> 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 <ja...@carmanconsulting.com> wrote:
> >> > >>> > I see the JIRA, I'll go ahead and start the discussion on the
> dev
> >> > list.
> >> > >>> >
> >> > >>> >
> >> > >>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
> >> > >>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
> >> > >>> For additional commands, e-mail: users-help@wicket.apache.org
> >> > >>>
> >> > >>>
> >> > >>
> >> > >>
> >> > >
> >> > > --
> >> > > 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@wicket.apache.org
> >> > > For additional commands, e-mail: users-help@wicket.apache.org
> >> > >
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: CompoundModel based on proxies
Posted by Johan Compagner <jc...@gmail.com>.
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
<mb...@gmail.com>wrote:
> On Wed, Oct 29, 2008 at 12:03 PM, Martijn Dashorst <
> martijn.dashorst@gmail.com> 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
> > <fr...@gmail.com> 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
> > >>> <mb...@gmail.com>wrote:
> > >>>
> > >>> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <
> > waynemailinglists@gmail.com
> > >>> >
> > >>> > 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@carmanconsulting.com>
> > >>> > >> 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 <ja...@carmanconsulting.com> wrote:
> > >>> > >>> > I see the JIRA, I'll go ahead and start the discussion on the
> > dev
> > >>> > list.
> > >>> > >>> >
> > >>> > >>> >
> > >>> > >>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
> > >>> > >>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
> > >>> > >>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>> > >>>
> > >>> > >>>
> > >>> > >>
> > >>> > >>
> > >>> > >
> > >>> > > --
> > >>> > > 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@wicket.apache.org
> > >>> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >>> > >
> > >>> > >
> > >>> >
> > >>> >
> ---------------------------------------------------------------------
> > >>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >>> > For additional commands, e-mail: users-help@wicket.apache.org
> > >>> >
> > >>> >
> > >>>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> >
> >
> > --
> > 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@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: CompoundModel based on proxies
Posted by Maarten Bosteels <mb...@gmail.com>.
On Wed, Oct 29, 2008 at 12:03 PM, Martijn Dashorst <
martijn.dashorst@gmail.com> 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
> <fr...@gmail.com> 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
> >>> <mb...@gmail.com>wrote:
> >>>
> >>> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <
> waynemailinglists@gmail.com
> >>> >
> >>> > 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@carmanconsulting.com>
> >>> > >> 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 <ja...@carmanconsulting.com> wrote:
> >>> > >>> > I see the JIRA, I'll go ahead and start the discussion on the
> dev
> >>> > list.
> >>> > >>> >
> >>> > >>> >
> >>> > >>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
> >>> > >>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
> >>> > >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>> > >>>
> >>> > >>>
> >>> > >>
> >>> > >>
> >>> > >
> >>> > > --
> >>> > > 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@wicket.apache.org
> >>> > > For additional commands, e-mail: users-help@wicket.apache.org
> >>> > >
> >>> > >
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> > For additional commands, e-mail: users-help@wicket.apache.org
> >>> >
> >>> >
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
>
> --
> 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@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: CompoundModel based on proxies
Posted by Martijn Dashorst <ma...@gmail.com>.
afiar the proxy based model is null safe.
Martijn
On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy
<fr...@gmail.com> 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
>>> <mb...@gmail.com>wrote:
>>>
>>> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@gmail.com
>>> >
>>> > 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@carmanconsulting.com>
>>> > >> 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 <ja...@carmanconsulting.com> wrote:
>>> > >>> > I see the JIRA, I'll go ahead and start the discussion on the dev
>>> > list.
>>> > >>> >
>>> > >>> >
>>> > >>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
>>> > >>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
>>> > >>> For additional commands, e-mail: users-help@wicket.apache.org
>>> > >>>
>>> > >>>
>>> > >>
>>> > >>
>>> > >
>>> > > --
>>> > > 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@wicket.apache.org
>>> > > For additional commands, e-mail: users-help@wicket.apache.org
>>> > >
>>> > >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>> >
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
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@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: CompoundModel based on proxies
Posted by francisco treacy <fr...@gmail.com>.
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
>> <mb...@gmail.com>wrote:
>>
>> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@gmail.com
>> >
>> > 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@carmanconsulting.com>
>> > >> 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 <ja...@carmanconsulting.com> wrote:
>> > >>> > I see the JIRA, I'll go ahead and start the discussion on the dev
>> > list.
>> > >>> >
>> > >>> >
>> > >>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
>> > >>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
>> > >>> For additional commands, e-mail: users-help@wicket.apache.org
>> > >>>
>> > >>>
>> > >>
>> > >>
>> > >
>> > > --
>> > > 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@wicket.apache.org
>> > > For additional commands, e-mail: users-help@wicket.apache.org
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: CompoundModel based on proxies
Posted by Maarten Bosteels <mb...@gmail.com>.
On Wed, Oct 29, 2008 at 10:54 AM, Wayne Pope <
waynemailinglists@googlemail.com> 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
> <mb...@gmail.com>wrote:
>
> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@gmail.com
> >
> > 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@carmanconsulting.com>
> > >> 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 <ja...@carmanconsulting.com> wrote:
> > >>> > I see the JIRA, I'll go ahead and start the discussion on the dev
> > list.
> > >>> >
> > >>> >
> > >>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
> > >>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
> > >>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>>
> > >>>
> > >>
> > >>
> > >
> > > --
> > > 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@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: CompoundModel based on proxies
Posted by Wayne Pope <wa...@googlemail.com>.
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
<mb...@gmail.com>wrote:
> On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <wa...@gmail.com>
> 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@carmanconsulting.com>
> >> 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 <ja...@carmanconsulting.com> wrote:
> >>> > I see the JIRA, I'll go ahead and start the discussion on the dev
> list.
> >>> >
> >>> >
> >>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
> >>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >>
> >
> > --
> > 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@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: CompoundModel based on proxies
Posted by James Carman <ja...@carmanconsulting.com>.
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
<fr...@gmail.com> 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
> <ja...@carmanconsulting.com> 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
>> <mb...@gmail.com> wrote:
>>> On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <wa...@gmail.com> 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 <ja...@carmanconsulting.com>
>>>>> 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 <ja...@carmanconsulting.com> wrote:
>>>>>> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>>>>> >
>>>>>> >
>>>>>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
>>>>>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: CompoundModel based on proxies
Posted by francisco treacy <fr...@gmail.com>.
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
<ja...@carmanconsulting.com> 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
> <mb...@gmail.com> wrote:
>> On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <wa...@gmail.com> 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 <ja...@carmanconsulting.com>
>>>> 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 <ja...@carmanconsulting.com> wrote:
>>>>> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>>>> >
>>>>> >
>>>>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
>>>>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> 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@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: CompoundModel based on proxies
Posted by James Carman <ja...@carmanconsulting.com>.
Sorry, but I am on many mailing lists as part of my open source
involvement. I apologize if I breezed over some of what you wrote. I
see now where you said you could use the Property API from that other
project, which is what I would suggest as opposed to IModel from the
Wicket library if you're going to use it in your "domain." I have a
bad habit of half-reading these emails just so I can keep up with the
volume of traffic from all of the lists. :)
On Wed, Oct 29, 2008 at 9:29 AM, Maarten Bosteels
<mb...@gmail.com> wrote:
> On Wed, Oct 29, 2008 at 2:24 PM, James Carman <ja...@carmanconsulting.com>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
>> <mb...@gmail.com> wrote:
>> > On Wed, Oct 29, 2008 at 1:09 PM, James Carman <
>> james@carmanconsulting.com>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
>> >> <mb...@gmail.com> wrote:
>> >> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <
>> waynemailinglists@gmail.com>
>> >> 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@carmanconsulting.com>
>> >> >>> 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 <ja...@carmanconsulting.com> wrote:
>> >> >>>> > I see the JIRA, I'll go ahead and start the discussion on the dev
>> >> list.
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
>> >> >>>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
>> >> >>>> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >> --
>> >> >> 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@wicket.apache.org
>> >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: CompoundModel based on proxies
Posted by Maarten Bosteels <mb...@gmail.com>.
On Wed, Oct 29, 2008 at 2:24 PM, James Carman <ja...@carmanconsulting.com>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
> <mb...@gmail.com> wrote:
> > On Wed, Oct 29, 2008 at 1:09 PM, James Carman <
> james@carmanconsulting.com>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
> >> <mb...@gmail.com> wrote:
> >> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <
> waynemailinglists@gmail.com>
> >> 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@carmanconsulting.com>
> >> >>> 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 <ja...@carmanconsulting.com> wrote:
> >> >>>> > I see the JIRA, I'll go ahead and start the discussion on the dev
> >> list.
> >> >>>> >
> >> >>>> >
> >> >>>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
> >> >>>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
> >> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>
> >> >> --
> >> >> 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@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: CompoundModel based on proxies
Posted by James Carman <ja...@carmanconsulting.com>.
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
<mb...@gmail.com> wrote:
> On Wed, Oct 29, 2008 at 1:09 PM, James Carman <ja...@carmanconsulting.com>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
>> <mb...@gmail.com> wrote:
>> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <wa...@gmail.com>
>> 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@carmanconsulting.com>
>> >>> 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 <ja...@carmanconsulting.com> wrote:
>> >>>> > I see the JIRA, I'll go ahead and start the discussion on the dev
>> list.
>> >>>> >
>> >>>> >
>> >>>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
>> >>>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
>> >>>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> 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@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: CompoundModel based on proxies
Posted by Maarten Bosteels <mb...@gmail.com>.
On Wed, Oct 29, 2008 at 1:09 PM, James Carman <ja...@carmanconsulting.com>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
> <mb...@gmail.com> wrote:
> > On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <wa...@gmail.com>
> 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@carmanconsulting.com>
> >>> 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 <ja...@carmanconsulting.com> wrote:
> >>>> > I see the JIRA, I'll go ahead and start the discussion on the dev
> list.
> >>>> >
> >>>> >
> >>>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
> >>>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>
> >> --
> >> 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@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: CompoundModel based on proxies
Posted by James Carman <ja...@carmanconsulting.com>.
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
<mb...@gmail.com> wrote:
> On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <wa...@gmail.com> 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 <ja...@carmanconsulting.com>
>>> 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 <ja...@carmanconsulting.com> wrote:
>>>> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>>> >
>>>> >
>>>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
>>>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>
>> --
>> 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@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: CompoundModel based on proxies
Posted by francisco treacy <fr...@gmail.com>.
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 <ja...@carmanconsulting.com>
>>> 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 <ja...@carmanconsulting.com> wrote:
>>>> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>>> >
>>>> >
>>>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
>>>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>
>> --
>> 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@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: CompoundModel based on proxies
Posted by Maarten Bosteels <mb...@gmail.com>.
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <wa...@gmail.com> 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 <ja...@carmanconsulting.com>
>> 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 <ja...@carmanconsulting.com> wrote:
>>> > I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>> >
>>> >
>>> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
>>> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>
> --
> 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@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: CompoundModel based on proxies
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
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 <ja...@carmanconsulting.com>
>> 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 <ja...@carmanconsulting.com> wrote:
>>>
>>>> I see the JIRA, I'll go ahead and start the discussion on the dev list.
>>>>
>>>>
>>>> On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
>>>> > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>
>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: CompoundModel based on proxies
Posted by Wayne Pope <wa...@googlemail.com>.
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 <jc...@gmail.com>wrote:
> wicket 1.5
>
> first 1.4 has to be released
>
> On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <waynemailinglists@gmail.com
> >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@carmanconsulting.com
> > >
> > > 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 <ja...@carmanconsulting.com> wrote:
> > >> > I see the JIRA, I'll go ahead and start the discussion on the dev
> > list.
> > >> >
> > >> >
> > >> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
> > >> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >>
> > >
> > >
> >
> > --
> > 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@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: CompoundModel based on proxies
Posted by Johan Compagner <jc...@gmail.com>.
wicket 1.5
first 1.4 has to be released
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope <wa...@gmail.com>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@carmanconsulting.com
> >
> > 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 <ja...@carmanconsulting.com> wrote:
> >> > I see the JIRA, I'll go ahead and start the discussion on the dev
> list.
> >> >
> >> >
> >> > On 3/8/08, James Carman <ja...@carmanconsulting.com> wrote:
> >> > > On 3/8/08, Johan Compagner <jc...@gmail.com> 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@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> 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@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>