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 [EMAIL PROTECTED] wrote: Couldn't you also do: ProxyFactory pf = ...; new SharedPropertyModelCustomer(pf, customer); So, the client tells you what proxy factory implementation to use. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: I see the JIRA, I'll go ahead and start the discussion on the dev list. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote: for wicket this is a feature it really should have now it defeats the purpose i have to make a decission in wicket which factory i use Then i can just as well directly compile against cglib. I cant make the api that way that the developer has to give that factory to use. That would be completely horrible, You could always implement your own brand of discovery for your project (perhaps by using the service discovery feature built into the jdk). I like the idea of splitting it (and doing it the slf4j way rather than the JCL way). I have actually suggested that we start an exploratory branch of JCL to make it work more like slf4j (we've been talking about this since 2005). Anyway, if you file a JIRA issue, I'll make sure we have a discussion with the other devs. For your immediate purposes, commons-discovery is available also. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
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 [EMAIL PROTECTED] wrote: Couldn't you also do: ProxyFactory pf = ...; new SharedPropertyModelCustomer(pf, customer); So, the client tells you what proxy factory implementation to use. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: I see the JIRA, I'll go ahead and start the discussion on the dev list. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote: for wicket this is a feature it really should have now it defeats the purpose i have to make a decission in wicket which factory i use Then i can just as well directly compile against cglib. I cant make the api that way that the developer has to give that factory to use. That would be completely horrible, You could always implement your own brand of discovery for your project (perhaps by using the service discovery feature built into the jdk). I like the idea of splitting it (and doing it the slf4j way rather than the JCL way). I have actually suggested that we start an exploratory branch of JCL to make it work more like slf4j (we've been talking about this since 2005). Anyway, if you file a JIRA issue, I'll make sure we have a discussion with the other devs. For your immediate purposes, commons-discovery is available also. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope [EMAIL PROTECTED] wrote:
Hi,
Francisco and I here where discussing whether we could figure a way of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about some nasty
runtime bugs that might slip through the testing coverage. Francisco found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been using this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin that
could just check for this (a bit like checkstyle or something) but a runtime
solution as proposed above seems really smart as well. However I'd rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models like this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city );
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an option.
and they have to program themselfs agains the proxy api. I dont want that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman [EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the dev list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to give that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for your
project (perhaps by using the service discovery feature built into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way rather
than the JCL way). I have actually suggested that we start an
exploratory branch of JCL to make it work more like slf4j (we've
been
talking about this since 2005). Anyway, if you file a JIRA issue,
I'll make sure we have a discussion with the other devs. For your
immediate purposes, commons-discovery is available also.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
Hi Maarten
interesting idea thanks. I think the major issue is the null pointer
checking.
for your:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
do you wrap this around you (hibernate/other) pojo's or are this additional
fields?
On Wed, Oct 29, 2008 at 10:42 AM, Maarten Bosteels
[EMAIL PROTECTED]wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope [EMAIL PROTECTED]
wrote:
Hi,
Francisco and I here where discussing whether we could figure a way of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about some
nasty
runtime bugs that might slip through the testing coverage. Francisco
found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been using
this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin that
could just check for this (a bit like checkstyle or something) but a
runtime
solution as proposed above seems really smart as well. However I'd rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city );
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an option.
and they have to program themselfs agains the proxy api. I dont want
that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman
[EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the dev
list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in
wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to give
that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for your
project (perhaps by using the service discovery feature built
into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way
rather
than the JCL way). I have actually suggested that we start an
exploratory branch of JCL to make it work more like slf4j (we've
been
talking about this since 2005). Anyway, if you file a JIRA
issue,
I'll make sure we have a discussion with the other devs. For
your
immediate purposes, commons-discovery is available also.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Re: CompoundModel based on proxies
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 [EMAIL PROTECTED]wrote: wicket 1.5 first 1.4 has to be released On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope [EMAIL PROTECTED] wrote: Hi, Francisco and I here where discussing whether we could figure a way of having some form of static/compile time checking on our (Compound)PropertyModels, as I'm a bit concerned long term about some nasty runtime bugs that might slip through the testing coverage. Francisco found this thread - I'm wondering what the status is? I had a look at: https://issues.apache.org/jira/browse/WICKET-1327 and there doesn't look like any activity since Feb. Anyone been using this or come up with a different solution? Ideally I think it would be just great if we had an eclipse plugin that could just check for this (a bit like checkstyle or something) but a runtime solution as proposed above seems really smart as well. However I'd rather keep is 100% java (ie not cglib) if possible. Thanks for any update if anyone knows anything! Wayne Johan Compagner wrote: no i really dont like that then everywhere there code they need to do that, that is not an option. and they have to program themselfs agains the proxy api. I dont want that developers also have the learn/do that This is something commons-proxy needs to do On Sat, Mar 8, 2008 at 3:29 PM, James Carman [EMAIL PROTECTED] wrote: Couldn't you also do: ProxyFactory pf = ...; new SharedPropertyModelCustomer(pf, customer); So, the client tells you what proxy factory implementation to use. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: I see the JIRA, I'll go ahead and start the discussion on the dev list. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote: for wicket this is a feature it really should have now it defeats the purpose i have to make a decission in wicket which factory i use Then i can just as well directly compile against cglib. I cant make the api that way that the developer has to give that factory to use. That would be completely horrible, You could always implement your own brand of discovery for your project (perhaps by using the service discovery feature built into the jdk). I like the idea of splitting it (and doing it the slf4j way rather than the JCL way). I have actually suggested that we start an exploratory branch of JCL to make it work more like slf4j (we've been talking about this since 2005). Anyway, if you file a JIRA issue, I'll make sure we have a discussion with the other devs. For your immediate purposes, commons-discovery is available also. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
hi, One problem I see with this approach is when you need null-checking for nested properties: eg: new TextFieldString(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 [EMAIL PROTECTED] wrote: Couldn't you also do: ProxyFactory pf = ...; new SharedPropertyModelCustomer(pf, customer); So, the client tells you what proxy factory implementation to use. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: I see the JIRA, I'll go ahead and start the discussion on the dev list. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote: for wicket this is a feature it really should have now it defeats the purpose i have to make a decission in wicket which factory i use Then i can just as well directly compile against cglib. I cant make the api that way that the developer has to give that factory to use. That would be completely horrible, You could always implement your own brand of discovery for your project (perhaps by using the service discovery feature built into the jdk). I like the idea of splitting it (and doing it the slf4j way rather than the JCL way). I have actually suggested that we start an exploratory branch of JCL to make it work more like slf4j (we've been talking about this since 2005). Anyway, if you file a JIRA issue, I'll make sure we have a discussion with the other devs. For your immediate purposes, commons-discovery is available also. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
On Wed, Oct 29, 2008 at 10:54 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
Hi Maarten
interesting idea thanks. I think the major issue is the null pointer
checking.
for your:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
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 PropertyString properties.
Did you know that bean-properties has its own ORM implementation:
https://bean-properties.dev.java.net/orm.html ?
I haven't tried it out yet though.
About the null checking, I will see if I can avoid having nested null values
in my proof-of-concept project.
Regards,
Maarten
On Wed, Oct 29, 2008 at 10:42 AM, Maarten Bosteels
[EMAIL PROTECTED]wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope [EMAIL PROTECTED]
wrote:
Hi,
Francisco and I here where discussing whether we could figure a way of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about some
nasty
runtime bugs that might slip through the testing coverage. Francisco
found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been using
this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin that
could just check for this (a bit like checkstyle or something) but a
runtime
solution as proposed above seems really smart as well. However I'd
rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city );
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an
option.
and they have to program themselfs agains the proxy api. I dont want
that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman
[EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the dev
list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in
wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to give
that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for your
project (perhaps by using the service discovery feature built
into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way
rather
than the JCL way). I have actually suggested that we start an
exploratory branch of JCL to make it work more like slf4j
(we've
been
talking about this since 2005). Anyway, if you file a JIRA
issue,
I'll make sure we have a discussion with the other devs. For
your
immediate purposes, commons-discovery is
Re: CompoundModel based on proxies
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
[EMAIL PROTECTED]wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope [EMAIL PROTECTED]
wrote:
Hi,
Francisco and I here where discussing whether we could figure a way of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about some
nasty
runtime bugs that might slip through the testing coverage. Francisco
found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been using
this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin that
could just check for this (a bit like checkstyle or something) but a
runtime
solution as proposed above seems really smart as well. However I'd
rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city );
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an
option.
and they have to program themselfs agains the proxy api. I dont want
that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman
[EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the dev
list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in
wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to give
that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for your
project (perhaps by using the service discovery feature built
into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way
rather
than the JCL way). I have actually suggested that we start an
exploratory branch of JCL to make it work more like slf4j
(we've
been
talking about this since 2005). Anyway, if you file a JIRA
issue,
I'll make sure we have a discussion with the other devs. For
your
immediate purposes, commons-discovery is available also.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Re: CompoundModel based on proxies
On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy
[EMAIL PROTECTED] wrote:
hi maarten
About the null checking, I will see if I can avoid having nested null
values
in my proof-of-concept project.
thing is the object chain is going to be resolved before it gets
passed in - there's nothing you can do about it inside your class :(
an eventual null pointer exception would be thrown before your
constructor is called.
Yes, of course. What I mean is that I would implement my class like this:
public class Customer {
public final PropertyAddress address = new PropertyImplAddress();
}
so evaluating customer.address.get().city will never throw a NPE.
When I really need to distingish between customers with or without an
address, I could add isNull()/setNull() to Address (or maybe even to the
Property interface itself).
Maarten
francisco
On Wed, Oct 29, 2008 at 10:42 AM, Maarten Bosteels
[EMAIL PROTECTED]wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope
[EMAIL PROTECTED]
wrote:
Hi,
Francisco and I here where discussing whether we could figure a way
of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about
some
nasty
runtime bugs that might slip through the testing coverage. Francisco
found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been
using
this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin
that
could just check for this (a bit like checkstyle or something) but a
runtime
solution as proposed above seems really smart as well. However I'd
rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models
like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city
);
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an
option.
and they have to program themselfs agains the proxy api. I dont
want
that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman
[EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the
dev
list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in
wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to
give
that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for
your
project (perhaps by using the service discovery feature
built
into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way
rather
than the JCL way). I have actually suggested that we start
an
exploratory branch of JCL to make it work more like slf4j
(we've
been
talking about this since 2005). Anyway, if you file a JIRA
issue,
I'll make sure we have a
Re: CompoundModel based on proxies
afiar the proxy based model is null safe.
Martijn
On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy
[EMAIL PROTECTED] wrote:
hi maarten
About the null checking, I will see if I can avoid having nested null values
in my proof-of-concept project.
thing is the object chain is going to be resolved before it gets
passed in - there's nothing you can do about it inside your class :(
an eventual null pointer exception would be thrown before your
constructor is called.
francisco
On Wed, Oct 29, 2008 at 10:42 AM, Maarten Bosteels
[EMAIL PROTECTED]wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope [EMAIL PROTECTED]
wrote:
Hi,
Francisco and I here where discussing whether we could figure a way of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about some
nasty
runtime bugs that might slip through the testing coverage. Francisco
found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been using
this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin that
could just check for this (a bit like checkstyle or something) but a
runtime
solution as proposed above seems really smart as well. However I'd
rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city );
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an
option.
and they have to program themselfs agains the proxy api. I dont want
that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman
[EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the dev
list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in
wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to give
that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for your
project (perhaps by using the service discovery feature built
into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way
rather
than the JCL way). I have actually suggested that we start an
exploratory branch of JCL to make it work more like slf4j
(we've
been
talking about this since 2005). Anyway, if you file a JIRA
issue,
I'll make sure we have a discussion with the other devs. For
your
immediate purposes, commons-discovery is available also.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.html
Sent from the Wicket - User mailing list archive at Nabble.com.
Re: CompoundModel based on proxies
On Wed, Oct 29, 2008 at 12:03 PM, Martijn Dashorst
[EMAIL PROTECTED] 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 TextFieldString (customer#address#city);
Maarten
On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy
[EMAIL PROTECTED] wrote:
hi maarten
About the null checking, I will see if I can avoid having nested null
values
in my proof-of-concept project.
thing is the object chain is going to be resolved before it gets
passed in - there's nothing you can do about it inside your class :(
an eventual null pointer exception would be thrown before your
constructor is called.
francisco
On Wed, Oct 29, 2008 at 10:42 AM, Maarten Bosteels
[EMAIL PROTECTED]wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope
[EMAIL PROTECTED]
wrote:
Hi,
Francisco and I here where discussing whether we could figure a way
of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about
some
nasty
runtime bugs that might slip through the testing coverage.
Francisco
found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been
using
this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin
that
could just check for this (a bit like checkstyle or something) but
a
runtime
solution as proposed above seems really smart as well. However I'd
rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models
like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city
);
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an
option.
and they have to program themselfs agains the proxy api. I dont
want
that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman
[EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to
use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the
dev
list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in
wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to
give
that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for
your
project (perhaps by using the service discovery feature
built
into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way
rather
than the JCL way). I have actually suggested that we start
an
exploratory branch of JCL to make it work more like slf4j
(we've
been
talking about this since 2005). Anyway, if you file a JIRA
issue,
I'll make sure we have a discussion with the other
Re: CompoundModel based on proxies
On Wed, Oct 29, 2008 at 12:02 PM, Maarten Bosteels
[EMAIL PROTECTED]wrote:
On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy
[EMAIL PROTECTED] wrote:
hi maarten
About the null checking, I will see if I can avoid having nested null
values
in my proof-of-concept project.
thing is the object chain is going to be resolved before it gets
passed in - there's nothing you can do about it inside your class :(
an eventual null pointer exception would be thrown before your
constructor is called.
Yes, of course. What I mean is that I would implement my class like this:
public class Customer {
public final PropertyAddress address = new PropertyImplAddress() {
@Override
public void set(Address value) {
if (value == null) {
throw new NullPointerException(address should not be null);
}
super.set(object);
}
};
so evaluating customer.address.get().city will never throw a NPE.
When I really need to distingish between customers with or without an
address, I could add isNull()/setNull() to Address (or maybe even to the
Property interface itself).
Maarten
francisco
On Wed, Oct 29, 2008 at 10:42 AM, Maarten Bosteels
[EMAIL PROTECTED]wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope
[EMAIL PROTECTED]
wrote:
Hi,
Francisco and I here where discussing whether we could figure a way
of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about
some
nasty
runtime bugs that might slip through the testing coverage.
Francisco
found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been
using
this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin
that
could just check for this (a bit like checkstyle or something) but
a
runtime
solution as proposed above seems really smart as well. However I'd
rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models
like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city
);
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an
option.
and they have to program themselfs agains the proxy api. I dont
want
that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman
[EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to
use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the
dev
list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in
wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to
give
that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for
your
project (perhaps by using the service discovery feature
built
into
the
jdk).
I like the idea of splitting
Re: CompoundModel based on proxies
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
[EMAIL PROTECTED]wrote:
On Wed, Oct 29, 2008 at 12:03 PM, Martijn Dashorst
[EMAIL PROTECTED] 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 TextFieldString (customer#address#city);
Maarten
On Wed, Oct 29, 2008 at 11:47 AM, francisco treacy
[EMAIL PROTECTED] wrote:
hi maarten
About the null checking, I will see if I can avoid having nested null
values
in my proof-of-concept project.
thing is the object chain is going to be resolved before it gets
passed in - there's nothing you can do about it inside your class :(
an eventual null pointer exception would be thrown before your
constructor is called.
francisco
On Wed, Oct 29, 2008 at 10:42 AM, Maarten Bosteels
[EMAIL PROTECTED]wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope
[EMAIL PROTECTED]
wrote:
Hi,
Francisco and I here where discussing whether we could figure a
way
of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about
some
nasty
runtime bugs that might slip through the testing coverage.
Francisco
found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been
using
this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse
plugin
that
could just check for this (a bit like checkstyle or something)
but
a
runtime
solution as proposed above seems really smart as well. However
I'd
rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models
like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city,
customer.address.getObject().city
);
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an
option.
and they have to program themselfs agains the proxy api. I dont
want
that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman
[EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to
use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the
dev
list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission
in
wicket
which
factory i use
Then i can just as well directly compile against
cglib.
I cant make the api that way that the developer has to
give
that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for
your
project (perhaps by using the service discovery feature
built
into
the
jdk).
I like
Re: CompoundModel based on proxies
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
[EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope [EMAIL PROTECTED] wrote:
Hi,
Francisco and I here where discussing whether we could figure a way of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about some nasty
runtime bugs that might slip through the testing coverage. Francisco found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been using this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin that
could just check for this (a bit like checkstyle or something) but a runtime
solution as proposed above seems really smart as well. However I'd rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models like this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city );
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an option.
and they have to program themselfs agains the proxy api. I dont want that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman [EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the dev list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to give that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for your
project (perhaps by using the service discovery feature built into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way rather
than the JCL way). I have actually suggested that we start an
exploratory branch of JCL to make it work more like slf4j (we've
been
talking about this since 2005). Anyway, if you file a JIRA issue,
I'll make sure we have a discussion with the other devs. For your
immediate purposes, commons-discovery is available also.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope [EMAIL PROTECTED] wrote:
Hi,
Francisco and I here where discussing whether we could figure a way of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about some nasty
runtime bugs that might slip through the testing coverage. Francisco found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been using this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin that
could just check for this (a bit like checkstyle or something) but a runtime
solution as proposed above seems really smart as well. However I'd rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models like this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city );
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an option.
and they have to program themselfs agains the proxy api. I dont want that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman [EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the dev list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to give that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for your
project (perhaps by using the service discovery feature built into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way rather
than the JCL way). I have actually suggested that we start an
exploratory branch of JCL to make it work more like slf4j (we've
been
talking about this since 2005). Anyway, if you file a JIRA issue,
I'll make sure we have a discussion with the other devs. For your
immediate purposes, commons-discovery is available also.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Re: CompoundModel based on proxies
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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope [EMAIL PROTECTED] wrote:
Hi,
Francisco and I here where discussing whether we could figure a way of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about some nasty
runtime bugs that might slip through the testing coverage. Francisco found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been using this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin that
could just check for this (a bit like checkstyle or something) but a
runtime
solution as proposed above seems really smart as well. However I'd rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city );
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an option.
and they have to program themselfs agains the proxy api. I dont want that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman [EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the dev list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to give that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for your
project (perhaps by using the service discovery feature built into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way rather
than the JCL way). I have actually suggested that we start an
exploratory branch of JCL to make it work more like slf4j (we've
been
talking about this since 2005). Anyway, if you file a JIRA issue,
I'll make sure we have a discussion with the other devs. For your
immediate purposes, commons-discovery is available also.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
On Wed, Oct 29, 2008 at 1:09 PM, James Carman [EMAIL PROTECTED]wrote:
You shouldn't muddy up your domain with view-specific logic (the
IModel interface).
In my example I just used IModelT instead of PropertyT 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
[EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope [EMAIL PROTECTED]
wrote:
Hi,
Francisco and I here where discussing whether we could figure a way of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about some
nasty
runtime bugs that might slip through the testing coverage. Francisco
found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been using
this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin that
could just check for this (a bit like checkstyle or something) but a
runtime
solution as proposed above seems really smart as well. However I'd
rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city );
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an option.
and they have to program themselfs agains the proxy api. I dont want
that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman
[EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the dev
list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in
wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to give
that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for your
project (perhaps by using the service discovery feature built
into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way
rather
than the JCL way). I have actually suggested that we start an
exploratory branch of JCL to make it work more like slf4j (we've
been
talking about this since 2005). Anyway, if you file a JIRA
issue,
I'll make sure we have a discussion with the other devs. For
your
immediate purposes, commons-discovery is available also.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p20222077.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Re: CompoundModel based on proxies
On Wed, Oct 29, 2008 at 2:24 PM, James Carman [EMAIL PROTECTED]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
[EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 1:09 PM, James Carman
[EMAIL PROTECTED]wrote:
You shouldn't muddy up your domain with view-specific logic (the
IModel interface).
In my example I just used IModelT instead of PropertyT 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
[EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope
[EMAIL PROTECTED]
wrote:
Hi,
Francisco and I here where discussing whether we could figure a way
of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about some
nasty
runtime bugs that might slip through the testing coverage. Francisco
found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been using
this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin
that
could just check for this (a bit like checkstyle or something) but a
runtime
solution as proposed above seems really smart as well. However I'd
rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models
like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city
);
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an
option.
and they have to program themselfs agains the proxy api. I dont want
that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman
[EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the dev
list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in
wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to
give
that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for
your
project (perhaps by using the service discovery feature built
into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way
rather
than the JCL way). I have actually suggested that we start
an
exploratory branch of JCL to make it work more like slf4j
(we've
been
talking about this since 2005). Anyway, if you file a JIRA
issue,
I'll make sure we have a discussion with the other devs. For
your
immediate purposes, commons-discovery is
Re: CompoundModel based on proxies
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
[EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 2:24 PM, James Carman [EMAIL PROTECTED]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
[EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 1:09 PM, James Carman
[EMAIL PROTECTED]wrote:
You shouldn't muddy up your domain with view-specific logic (the
IModel interface).
In my example I just used IModelT instead of PropertyT 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
[EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope
[EMAIL PROTECTED]
wrote:
Hi,
Francisco and I here where discussing whether we could figure a way
of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about some
nasty
runtime bugs that might slip through the testing coverage. Francisco
found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been using
this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin
that
could just check for this (a bit like checkstyle or something) but a
runtime
solution as proposed above seems really smart as well. However I'd
rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models
like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city
);
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an
option.
and they have to program themselfs agains the proxy api. I dont want
that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman
[EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the dev
list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in
wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to
give
that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for
your
Re: CompoundModel based on proxies
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
[EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 1:09 PM, James Carman [EMAIL PROTECTED]wrote:
You shouldn't muddy up your domain with view-specific logic (the
IModel interface).
In my example I just used IModelT instead of PropertyT 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
[EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 8:35 AM, Wayne Pope [EMAIL PROTECTED]
wrote:
Hi,
Francisco and I here where discussing whether we could figure a way of
having some form of static/compile time checking on our
(Compound)PropertyModels, as I'm a bit concerned long term about some
nasty
runtime bugs that might slip through the testing coverage. Francisco
found
this thread - I'm wondering what the status is? I had a look at:
https://issues.apache.org/jira/browse/WICKET-1327
and there doesn't look like any activity since Feb. Anyone been using
this
or come up with a different solution?
Ideally I think it would be just great if we had an eclipse plugin that
could just check for this (a bit like checkstyle or something) but a
runtime
solution as proposed above seems really smart as well. However I'd
rather
keep is 100% java (ie not cglib) if possible.
Hello,
If you want something 100% java you could copde your domain models like
this:
public class Customer implements Serializable {
public final IModelString firstName = new ModelString();
public final IModelString lastName = new ModelString();
}
and use it like this:
form.add(new TextFieldString(firstName, customer.firstName));
form.add(new TextFieldString(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 PropertyString 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 TextFieldString(city, customer.address.getObject().city );
Let me know what you think about it.
Maarten
Thanks for any update if anyone knows anything!
Wayne
Johan Compagner wrote:
no i really dont like that
then everywhere there code they need to do that, that is not an option.
and they have to program themselfs agains the proxy api. I dont want
that
developers also have the learn/do that
This is something commons-proxy needs to do
On Sat, Mar 8, 2008 at 3:29 PM, James Carman
[EMAIL PROTECTED]
wrote:
Couldn't you also do:
ProxyFactory pf = ...;
new SharedPropertyModelCustomer(pf, customer);
So, the client tells you what proxy factory implementation to use.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
I see the JIRA, I'll go ahead and start the discussion on the dev
list.
On 3/8/08, James Carman [EMAIL PROTECTED] wrote:
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote:
for wicket this is a feature it really should have
now it defeats the purpose i have to make a decission in
wicket
which
factory i use
Then i can just as well directly compile against cglib.
I cant make the api that way that the developer has to give
that
factory to
use. That would be completely horrible,
You could always implement your own brand of discovery for your
project (perhaps by using the service discovery feature built
into
the
jdk).
I like the idea of splitting it (and doing it the slf4j way
rather
than the JCL way). I have actually suggested that we start an
exploratory branch of JCL to make it work more like slf4j (we've
been
talking about this since 2005). Anyway, if you file a JIRA
issue,
I'll make sure we have a discussion with the other devs. For
your
immediate purposes, commons-discovery is available also.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
Re: CompoundModel based on proxies
Well, it'll be built into v1.1 if you need it. :) I took care of that yesterday. It wasn't as easy as it might seem to make sure your proxies are serializable. CGLIB didn't want to play nice. They don't make their NoOp classes serializable for some reason. I had a little easier time with Javassist and JDK proxies. I am playing now with the commons-proxy But i dont get what method to call to get the right ProxyFactory.. You dont say that i have to use at compile time one of the ProxyFactory implementations right? Because then the whole purpose of commons-proxy is gone. The thing is i want to be able to call something like this: ProxyFactory factory = ProxyFactory.getInstance() and then what ever instance i get back depends on configuration or classpath I like the SLF4J approache where you just drop you wanted implementation in the classpath and you are done. But the commons-logging also works for me where you set it in a property file which one to use. But that last one has classloading problems i think so maybe it is not a good idea to copy that... So to mimic the slf4j you should have: commons-proxy-api.jar commons-proxy-cglib.jar commons-proxy-javaassist.jar and then if you want to use cglib drop in the commons api and the commons cglib jar with the cglib jar itself. johan
Re: CompoundModel based on proxies
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote: Well, it'll be built into v1.1 if you need it. :) I took care of that yesterday. It wasn't as easy as it might seem to make sure your proxies are serializable. CGLIB didn't want to play nice. They don't make their NoOp classes serializable for some reason. I had a little easier time with Javassist and JDK proxies. I am playing now with the commons-proxy But i dont get what method to call to get the right ProxyFactory.. You dont say that i have to use at compile time one of the ProxyFactory implementations right? Because then the whole purpose of commons-proxy is gone. The thing is i want to be able to call something like this: ProxyFactory factory = ProxyFactory.getInstance() and then what ever instance i get back depends on configuration or classpath I like the SLF4J approache where you just drop you wanted implementation in the classpath and you are done. But the commons-logging also works for me where you set it in a property file which one to use. But that last one has classloading problems i think so maybe it is not a good idea to copy that... So to mimic the slf4j you should have: commons-proxy-api.jar commons-proxy-cglib.jar commons-proxy-javaassist.jar and then if you want to use cglib drop in the commons api and the commons cglib jar with the cglib jar itself. Commons Proxy has no discovery built into it. It's not really designed for that. You just need to instantiate what you want. File a JIRA for adding slf4j-like discovery and I'll post a discussion to the rest of the dev list about it. johan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
On 3/8/08, James Carman [EMAIL PROTECTED] wrote: On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote: Well, it'll be built into v1.1 if you need it. :) I took care of that yesterday. It wasn't as easy as it might seem to make sure your proxies are serializable. CGLIB didn't want to play nice. They don't make their NoOp classes serializable for some reason. I had a little easier time with Javassist and JDK proxies. I am playing now with the commons-proxy But i dont get what method to call to get the right ProxyFactory.. You dont say that i have to use at compile time one of the ProxyFactory implementations right? Because then the whole purpose of commons-proxy is gone. The thing is i want to be able to call something like this: ProxyFactory factory = ProxyFactory.getInstance() and then what ever instance i get back depends on configuration or classpath I like the SLF4J approache where you just drop you wanted implementation in the classpath and you are done. But the commons-logging also works for me where you set it in a property file which one to use. But that last one has classloading problems i think so maybe it is not a good idea to copy that... So to mimic the slf4j you should have: commons-proxy-api.jar commons-proxy-cglib.jar commons-proxy-javaassist.jar and then if you want to use cglib drop in the commons api and the commons cglib jar with the cglib jar itself. Commons Proxy has no discovery built into it. It's not really designed for that. You just need to instantiate what you want. File a JIRA for adding slf4j-like discovery and I'll post a discussion to the rest of the dev list about it. That should have been Please file a JIRA. :) johan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
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, johan On Sat, Mar 8, 2008 at 1:15 PM, James Carman [EMAIL PROTECTED] wrote: On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote: Well, it'll be built into v1.1 if you need it. :) I took care of that yesterday. It wasn't as easy as it might seem to make sure your proxies are serializable. CGLIB didn't want to play nice. They don't make their NoOp classes serializable for some reason. I had a little easier time with Javassist and JDK proxies. I am playing now with the commons-proxy But i dont get what method to call to get the right ProxyFactory.. You dont say that i have to use at compile time one of the ProxyFactory implementations right? Because then the whole purpose of commons-proxy is gone. The thing is i want to be able to call something like this: ProxyFactory factory = ProxyFactory.getInstance() and then what ever instance i get back depends on configuration or classpath I like the SLF4J approache where you just drop you wanted implementation in the classpath and you are done. But the commons-logging also works for me where you set it in a property file which one to use. But that last one has classloading problems i think so maybe it is not a good idea to copy that... So to mimic the slf4j you should have: commons-proxy-api.jar commons-proxy-cglib.jar commons-proxy-javaassist.jar and then if you want to use cglib drop in the commons api and the commons cglib jar with the cglib jar itself. Commons Proxy has no discovery built into it. It's not really designed for that. You just need to instantiate what you want. File a JIRA for adding slf4j-like discovery and I'll post a discussion to the rest of the dev list about it. johan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote: for wicket this is a feature it really should have now it defeats the purpose i have to make a decission in wicket which factory i use Then i can just as well directly compile against cglib. I cant make the api that way that the developer has to give that factory to use. That would be completely horrible, You could always implement your own brand of discovery for your project (perhaps by using the service discovery feature built into the jdk). I like the idea of splitting it (and doing it the slf4j way rather than the JCL way). I have actually suggested that we start an exploratory branch of JCL to make it work more like slf4j (we've been talking about this since 2005). Anyway, if you file a JIRA issue, I'll make sure we have a discussion with the other devs. For your immediate purposes, commons-discovery is available also. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
I see the JIRA, I'll go ahead and start the discussion on the dev list. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote: for wicket this is a feature it really should have now it defeats the purpose i have to make a decission in wicket which factory i use Then i can just as well directly compile against cglib. I cant make the api that way that the developer has to give that factory to use. That would be completely horrible, You could always implement your own brand of discovery for your project (perhaps by using the service discovery feature built into the jdk). I like the idea of splitting it (and doing it the slf4j way rather than the JCL way). I have actually suggested that we start an exploratory branch of JCL to make it work more like slf4j (we've been talking about this since 2005). Anyway, if you file a JIRA issue, I'll make sure we have a discussion with the other devs. For your immediate purposes, commons-discovery is available also. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
Couldn't you also do: ProxyFactory pf = ...; new SharedPropertyModelCustomer(pf, customer); So, the client tells you what proxy factory implementation to use. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: I see the JIRA, I'll go ahead and start the discussion on the dev list. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote: for wicket this is a feature it really should have now it defeats the purpose i have to make a decission in wicket which factory i use Then i can just as well directly compile against cglib. I cant make the api that way that the developer has to give that factory to use. That would be completely horrible, You could always implement your own brand of discovery for your project (perhaps by using the service discovery feature built into the jdk). I like the idea of splitting it (and doing it the slf4j way rather than the JCL way). I have actually suggested that we start an exploratory branch of JCL to make it work more like slf4j (we've been talking about this since 2005). Anyway, if you file a JIRA issue, I'll make sure we have a discussion with the other devs. For your immediate purposes, commons-discovery is available also. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
no i really dont like that then everywhere there code they need to do that, that is not an option. and they have to program themselfs agains the proxy api. I dont want that developers also have the learn/do that This is something commons-proxy needs to do On Sat, Mar 8, 2008 at 3:29 PM, James Carman [EMAIL PROTECTED] wrote: Couldn't you also do: ProxyFactory pf = ...; new SharedPropertyModelCustomer(pf, customer); So, the client tells you what proxy factory implementation to use. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: I see the JIRA, I'll go ahead and start the discussion on the dev list. On 3/8/08, James Carman [EMAIL PROTECTED] wrote: On 3/8/08, Johan Compagner [EMAIL PROTECTED] wrote: for wicket this is a feature it really should have now it defeats the purpose i have to make a decission in wicket which factory i use Then i can just as well directly compile against cglib. I cant make the api that way that the developer has to give that factory to use. That would be completely horrible, You could always implement your own brand of discovery for your project (perhaps by using the service discovery feature built into the jdk). I like the idea of splitting it (and doing it the slf4j way rather than the JCL way). I have actually suggested that we start an exploratory branch of JCL to make it work more like slf4j (we've been talking about this since 2005). Anyway, if you file a JIRA issue, I'll make sure we have a discussion with the other devs. For your immediate purposes, commons-discovery is available also. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
Serialization is not a problem for what we have build now because we dont keep references to the proxies in the session. We just use them at construction time On 2/27/08, James Carman [EMAIL PROTECTED] wrote: On 2/26/08, Johan Compagner [EMAIL PROTECTED] wrote: Yes i would like to have something like commons proxy because i dont want if possible a direct dependency on cglib. It would be coool that we have a default impl that is based on jdk itself (so only interface support). Then drop in cglib and you have support for also classes As soon as the mirrors pick up the release and it's available in the maven2 repository, I'll send out the 1.0 release announcement email. If you just can't wait, you can grab the distribution files from: http://www.apache.org/dist/commons/proxy/ The website has already been updated: http://commons.apache.org/proxy/ One thing that I think you'll be missing is serialization of the proxies. After I thought about it a bit, I don't think I made all proxies serializable. I'll put in a JIRA for that and get that out in a 1.1 release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
On 2/26/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote: The proxy based approach solves exactly this problem. Wow, fancy! :-) Thanks for sharing it, we'll probably use it too. The rest is by no means ment to discredit your effort, more like the devils advocate grumbling in front of the TV about Java in general: Isn't the JavaBean as key-value datastructure the real problem? We were lucky to be able to use a Map at one place in our wicket code for a reflective model object instead: CompoundPropertyModel supports it uniformly. Do people ever use non trivial getters and setters in their JavaBeans? We don't. Type safety and JPA are nice though, so we use JavaBeans everywhere else :-) But I just can't help wondering how the complexity (and performance) of current reflection/bytecode generation efforts would compare to porting all the JavaBean based tools and utilities to some different datastructure convention? One designed for programmatic manipulation. Like a Map where the key contains the type of the value. Some EnumMap-like optimisation could be employed when the keys are known compile-time. Would cover 90% of the cases people use reflection for currently I expect. Just imagine, JAXB could be a utility class with 2 static methods: encode and decode :-) Gabor Szokoli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
On 2/26/08, James Carman [EMAIL PROTECTED] wrote: Well, if you wait a bit until I do another release of Commons Proxy, it'll have that feature built in. Also, you could use Javassist if you wanted to very easily. Actually, after I played around a bit, it looks like CGLIB does this out of the box. So, it was caching your stuff already for you. Thus, Commons Proxy would be too. I had to create custom support for caching for Javassist, though. JDK proxy classes are cached automatically also by the java.lang.reflect.Proxy class. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
On 2/26/08, Johan Compagner [EMAIL PROTECTED] wrote: Yes i would like to have something like commons proxy because i dont want if possible a direct dependency on cglib. It would be coool that we have a default impl that is based on jdk itself (so only interface support). Then drop in cglib and you have support for also classes As soon as the mirrors pick up the release and it's available in the maven2 repository, I'll send out the 1.0 release announcement email. If you just can't wait, you can grab the distribution files from: http://www.apache.org/dist/commons/proxy/ The website has already been updated: http://commons.apache.org/proxy/ One thing that I think you'll be missing is serialization of the proxies. After I thought about it a bit, I don't think I made all proxies serializable. I'll put in a JIRA for that and get that out in a 1.1 release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
Hello, On Tue, 26 Feb 2008, Sebastiaan van Erk wrote: Then a refactor of the customerName property (and the getCustomerName() method) in an IDE such as Eclipse or NetBeans will *silently* break the above code, which you will discover only at runtime... The proxy based approach solves exactly this problem. We have found extensive developer tests (produced with TDD / BDD) to be a very effective solution to this problem. I prefer the current, terser syntax because of better readability, even though the string literals breaking in refactorings bother me too. It's a pity that Java in its current state seems to force one to produce a lot of clutter in the proxy-based approach, which is otherwise a very neat idea. For a Wicket UI, it's fairly easy to get 100 % branch coverage. And behavior-driving your code is more effective than just writing it anyway (produces better code faster), so it's a double win :) Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
Matej Knopp wrote: model.getFirstName() can't really return IModel, if Customer.getFirstName() returns string. Anyway, I like the idea, but I don't like the syntax. instead of one line [add(new TextField(id, model).setRequred(true)) ] you have now three separate lines. So I was thinking of something more like SafePropertyModelCustomer model = new SafePropertyModelCustomer(customer); add(new TextField(tf, model.bind(model.proxy().getCustomerName() )).setRequired(true)); This way you can have it one one line. -Matej So proxy() returns a Customer proxy? And model.bind() takes an Object argument (considering we don't know in advance what type getCustomerName() returns)... What about primitive types? Overload bind() for those as well? And the call to getCustomerName() has the side effect of setting a model object somewhere (e.g., in an instance field of model) which model.bind() can subsequently return? Very interesting. I don't like the proxy() method name though. If you call it something like property() it will look more like you're binding to a property of Customer: model.bind(model.property().getCustomerName()) VERY neat idea though... :-) Regards, Sebastiaan On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner [EMAIL PROTECTED] wrote: don't worry about creating the models That will happen anyway in 1.3 (that needs to be done for example to get the right object especially when we generify stuff) see CompoundPropertyModel.wrapOnInheritance() joan On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED] wrote: Interesting. So model.getFirstName() would return a PropetyModel based on the results of proxy.eval()? If I understand you correctly that creates many models (one per component) instead of reusing a single model, but that may well not be the end of the world. Or does getFirstName() return a CompoundModel that is properly bound this this component? Intriguing none the less. I hadn't considered this option, but I'm going to play with it a bit. I rather like that direction. On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED] wrote: i try to look at this this weekend, but i have a quick question I find it a bit verbose can't it be a bit shorter like this (just an example) SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName, model.getFirstName()).setRequired(true); add(firstName); where getFirstName() returns the model johan On Feb 6, 2008 6:57 PM, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: CompoundModel based on proxies
model.getFirstName() can't really return IModel, if Customer.getFirstName() returns string. Anyway, I like the idea, but I don't like the syntax. instead of one line [add(new TextField(id, model).setRequred(true)) ] you have now three separate lines. So I was thinking of something more like SafePropertyModelCustomer model = new SafePropertyModelCustomer(customer); add(new TextField(tf, model.bind(model.proxy().getCustomerName() )).setRequired(true)); This way you can have it one one line. -Matej On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner [EMAIL PROTECTED] wrote: don't worry about creating the models That will happen anyway in 1.3 (that needs to be done for example to get the right object especially when we generify stuff) see CompoundPropertyModel.wrapOnInheritance() joan On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED] wrote: Interesting. So model.getFirstName() would return a PropetyModel based on the results of proxy.eval()? If I understand you correctly that creates many models (one per component) instead of reusing a single model, but that may well not be the end of the world. Or does getFirstName() return a CompoundModel that is properly bound this this component? Intriguing none the less. I hadn't considered this option, but I'm going to play with it a bit. I rather like that direction. On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED] wrote: i try to look at this this weekend, but i have a quick question I find it a bit verbose can't it be a bit shorter like this (just an example) SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName, model.getFirstName()).setRequired(true); add(firstName); where getFirstName() returns the model johan On Feb 6, 2008 6:57 PM, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Resizable and reorderable grid components. http://www.inmethod.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
Hi, On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: model.getFirstName() can't really return IModel, if Customer.getFirstName() returns string. Anyway, I like the idea, but I don't like the syntax. instead of one line [add(new TextField(id, model).setRequred(true)) ] you have now three separate lines. So I was thinking of something more like SafePropertyModelCustomer model = new SafePropertyModelCustomer(customer); add(new TextField(tf, model.bind(model.proxy().getCustomerName() )).setRequired(true)); This way you can have it one one line. -Matej So proxy() returns a Customer proxy? And model.bind() takes an Object argument (considering we don't know in advance what type getCustomerName() returns)... What about primitive types? Overload bind() for those as well? Well, the return object is not important at all. What is important is the getCustomerName() call. That marks somewhere in the model that last accessed property was called customerName. and then immediately after this model.bind takes this information. And the call to getCustomerName() has the side effect of setting a model object somewhere (e.g., in an instance field of model) which model.bind() can subsequently return? Model bind will return a model (variation of propertymodel probably). It will take the information that getCustomerName call on proxy provided. Very interesting. I don't like the proxy() method name though. If you call it something like property() it will look more like you're binding to a property of Customer: Well, the naming can certainly be improved. I'm not sure about property() though. Well, we can discuss this more anyway. model.bind(model.property().getCustomerName()) VERY neat idea though... :-) Thanks. -Matej Regards, Sebastiaan On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner [EMAIL PROTECTED] wrote: don't worry about creating the models That will happen anyway in 1.3 (that needs to be done for example to get the right object especially when we generify stuff) see CompoundPropertyModel.wrapOnInheritance() joan On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED] wrote: Interesting. So model.getFirstName() would return a PropetyModel based on the results of proxy.eval()? If I understand you correctly that creates many models (one per component) instead of reusing a single model, but that may well not be the end of the world. Or does getFirstName() return a CompoundModel that is properly bound this this component? Intriguing none the less. I hadn't considered this option, but I'm going to play with it a bit. I rather like that direction. On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED] wrote: i try to look at this this weekend, but i have a quick question I find it a bit verbose can't it be a bit shorter like this (just an example) SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName, model.getFirstName()).setRequired(true); add(firstName); where getFirstName() returns the model johan On Feb 6, 2008 6:57 PM, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity.
Re: CompoundModel based on proxies
Matej Knopp wrote: Hi, On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: model.getFirstName() can't really return IModel, if Customer.getFirstName() returns string. Anyway, I like the idea, but I don't like the syntax. instead of one line [add(new TextField(id, model).setRequred(true)) ] you have now three separate lines. So I was thinking of something more like SafePropertyModelCustomer model = new SafePropertyModelCustomer(customer); add(new TextField(tf, model.bind(model.proxy().getCustomerName() )).setRequired(true)); This way you can have it one one line. -Matej So proxy() returns a Customer proxy? And model.bind() takes an Object argument (considering we don't know in advance what type getCustomerName() returns)... What about primitive types? Overload bind() for those as well? Well, the return object is not important at all. What is important is the getCustomerName() call. That marks somewhere in the model that last accessed property was called customerName. and then immediately after this model.bind takes this information. OK, that's what I described. :-) And I was being stupid with respect to the overloading. If bind takes an object as argument, then overloading will not be necessary due to autoboxing. :-) And the call to getCustomerName() has the side effect of setting a model object somewhere (e.g., in an instance field of model) which model.bind() can subsequently return? Model bind will return a model (variation of propertymodel probably). It will take the information that getCustomerName call on proxy provided. Ok, so the proxy remembers which getter was called last, and you use that to construct the model in bind(). Of course. Very interesting. I don't like the proxy() method name though. If you call it something like property() it will look more like you're binding to a property of Customer: Well, the naming can certainly be improved. I'm not sure about property() though. Well, we can discuss this more anyway. model.bind(model.property().getCustomerName()) Neither am I. :-) For one, it's quite long. But on the other hand, you do bind to a model property, and so it reads ok. I think that proxies should be invisible for general users, so they shouldn't have to understand the magic going on here, nor that proxies are involved. VERY neat idea though... :-) Thanks. What I really like about this solution is that it can be implemented completely separately from wicket-core, so you can just put it in it's own project. :-) Regards, Sebastiaan -Matej Regards, Sebastiaan On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner [EMAIL PROTECTED] wrote: don't worry about creating the models That will happen anyway in 1.3 (that needs to be done for example to get the right object especially when we generify stuff) see CompoundPropertyModel.wrapOnInheritance() joan On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED] wrote: Interesting. So model.getFirstName() would return a PropetyModel based on the results of proxy.eval()? If I understand you correctly that creates many models (one per component) instead of reusing a single model, but that may well not be the end of the world. Or does getFirstName() return a CompoundModel that is properly bound this this component? Intriguing none the less. I hadn't considered this option, but I'm going to play with it a bit. I rather like that direction. On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED] wrote: i try to look at this this weekend, but i have a quick question I find it a bit verbose can't it be a bit shorter like this (just an example) SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName, model.getFirstName()).setRequired(true); add(firstName); where getFirstName() returns the model johan On Feb 6, 2008 6:57 PM, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName);
Re: CompoundModel based on proxies
We've reworked the implementation a bit,it works like this: SafePropertyModelPerson p = new SafePropertyModelPerson(new Person()); TextField field = new TextField(name, p.bind(p.property().getFirstName())); It's attached to the JIRA issue: https://issues.apache.org/jira/browse/WICKET-1327 -Matej On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: Hi, On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: model.getFirstName() can't really return IModel, if Customer.getFirstName() returns string. Anyway, I like the idea, but I don't like the syntax. instead of one line [add(new TextField(id, model).setRequred(true)) ] you have now three separate lines. So I was thinking of something more like SafePropertyModelCustomer model = new SafePropertyModelCustomer(customer); add(new TextField(tf, model.bind(model.proxy().getCustomerName() )).setRequired(true)); This way you can have it one one line. -Matej So proxy() returns a Customer proxy? And model.bind() takes an Object argument (considering we don't know in advance what type getCustomerName() returns)... What about primitive types? Overload bind() for those as well? Well, the return object is not important at all. What is important is the getCustomerName() call. That marks somewhere in the model that last accessed property was called customerName. and then immediately after this model.bind takes this information. OK, that's what I described. :-) And I was being stupid with respect to the overloading. If bind takes an object as argument, then overloading will not be necessary due to autoboxing. :-) And the call to getCustomerName() has the side effect of setting a model object somewhere (e.g., in an instance field of model) which model.bind() can subsequently return? Model bind will return a model (variation of propertymodel probably). It will take the information that getCustomerName call on proxy provided. Ok, so the proxy remembers which getter was called last, and you use that to construct the model in bind(). Of course. Very interesting. I don't like the proxy() method name though. If you call it something like property() it will look more like you're binding to a property of Customer: Well, the naming can certainly be improved. I'm not sure about property() though. Well, we can discuss this more anyway. model.bind(model.property().getCustomerName()) Neither am I. :-) For one, it's quite long. But on the other hand, you do bind to a model property, and so it reads ok. I think that proxies should be invisible for general users, so they shouldn't have to understand the magic going on here, nor that proxies are involved. VERY neat idea though... :-) Thanks. What I really like about this solution is that it can be implemented completely separately from wicket-core, so you can just put it in it's own project. :-) Regards, Sebastiaan -Matej Regards, Sebastiaan On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner [EMAIL PROTECTED] wrote: don't worry about creating the models That will happen anyway in 1.3 (that needs to be done for example to get the right object especially when we generify stuff) see CompoundPropertyModel.wrapOnInheritance() joan On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED] wrote: Interesting. So model.getFirstName() would return a PropetyModel based on the results of proxy.eval()? If I understand you correctly that creates many models (one per component) instead of reusing a single model, but that may well not be the end of the world. Or does getFirstName() return a CompoundModel that is properly bound this this component? Intriguing none the less. I hadn't considered this option, but I'm going to play with it a bit. I rather like that direction. On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED] wrote: i try to look at this this weekend, but i have a quick question I find it a bit verbose can't it be a bit shorter like this (just an example) SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName, model.getFirstName()).setRequired(true); add(firstName); where getFirstName() returns the model johan On Feb 6, 2008 6:57 PM, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a
Re: CompoundModel based on proxies
I just added a relevant note about serialization (learned the hard way...) to the jira. - Scott On Tue, Feb 26, 2008 at 3:18 AM, Matej Knopp [EMAIL PROTECTED] wrote: We've reworked the implementation a bit,it works like this: SafePropertyModelPerson p = new SafePropertyModelPerson(new Person()); TextField field = new TextField(name, p.bind(p.property().getFirstName())); It's attached to the JIRA issue: https://issues.apache.org/jira/browse/WICKET-1327 -Matej - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
I feel this approach does NOT solve a problem.Its just an alternative .. On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp [EMAIL PROTECTED] wrote: We've reworked the implementation a bit,it works like this: SafePropertyModelPerson p = new SafePropertyModelPerson(new Person()); TextField field = new TextField(name, p.bind(p.property ().getFirstName())); It's attached to the JIRA issue: https://issues.apache.org/jira/browse/WICKET-1327 -Matej On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: Hi, On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: model.getFirstName() can't really return IModel, if Customer.getFirstName() returns string. Anyway, I like the idea, but I don't like the syntax. instead of one line [add(new TextField(id, model).setRequred(true)) ] you have now three separate lines. So I was thinking of something more like SafePropertyModelCustomer model = new SafePropertyModelCustomer(customer); add(new TextField(tf, model.bind(model.proxy ().getCustomerName() )).setRequired(true)); This way you can have it one one line. -Matej So proxy() returns a Customer proxy? And model.bind() takes an Object argument (considering we don't know in advance what type getCustomerName() returns)... What about primitive types? Overload bind() for those as well? Well, the return object is not important at all. What is important is the getCustomerName() call. That marks somewhere in the model that last accessed property was called customerName. and then immediately after this model.bind takes this information. OK, that's what I described. :-) And I was being stupid with respect to the overloading. If bind takes an object as argument, then overloading will not be necessary due to autoboxing. :-) And the call to getCustomerName() has the side effect of setting a model object somewhere (e.g., in an instance field of model) which model.bind() can subsequently return? Model bind will return a model (variation of propertymodel probably). It will take the information that getCustomerName call on proxy provided. Ok, so the proxy remembers which getter was called last, and you use that to construct the model in bind(). Of course. Very interesting. I don't like the proxy() method name though. If you call it something like property() it will look more like you're binding to a property of Customer: Well, the naming can certainly be improved. I'm not sure about property() though. Well, we can discuss this more anyway. model.bind(model.property().getCustomerName()) Neither am I. :-) For one, it's quite long. But on the other hand, you do bind to a model property, and so it reads ok. I think that proxies should be invisible for general users, so they shouldn't have to understand the magic going on here, nor that proxies are involved. VERY neat idea though... :-) Thanks. What I really like about this solution is that it can be implemented completely separately from wicket-core, so you can just put it in it's own project. :-) Regards, Sebastiaan -Matej Regards, Sebastiaan On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner [EMAIL PROTECTED] wrote: don't worry about creating the models That will happen anyway in 1.3 (that needs to be done for example to get the right object especially when we generify stuff) see CompoundPropertyModel.wrapOnInheritance() joan On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED] wrote: Interesting. So model.getFirstName() would return a PropetyModel based on the results of proxy.eval()? If I understand you correctly that creates many models (one per component) instead of reusing a single model, but that may well not be the end of the world. Or does getFirstName() return a CompoundModel that is properly bound this this component? Intriguing none the less. I hadn't considered this option, but I'm going to play with it a bit. I rather like that direction. On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED] wrote: i try to look at this this weekend, but i have a quick question I find it a bit verbose can't it be a bit shorter like this (just an example) SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName,
Re: CompoundModel based on proxies
Well, there's a problem with normal PropertyModels (or CompoundPropertyModels). For example, if you have the following textfield: TextField tf = new TextField(name, new PropertyModel(customer, customerName)); Then a refactor of the customerName property (and the getCustomerName() method) in an IDE such as Eclipse or NetBeans will *silently* break the above code, which you will discover only at runtime... The proxy based approach solves exactly this problem. Regards, Sebastiaan atul singh wrote: I feel this approach does NOT solve a problem.Its just an alternative .. On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp [EMAIL PROTECTED] wrote: We've reworked the implementation a bit,it works like this: SafePropertyModelPerson p = new SafePropertyModelPerson(new Person()); TextField field = new TextField(name, p.bind(p.property ().getFirstName())); It's attached to the JIRA issue: https://issues.apache.org/jira/browse/WICKET-1327 -Matej On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: Hi, On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: model.getFirstName() can't really return IModel, if Customer.getFirstName() returns string. Anyway, I like the idea, but I don't like the syntax. instead of one line [add(new TextField(id, model).setRequred(true)) ] you have now three separate lines. So I was thinking of something more like SafePropertyModelCustomer model = new SafePropertyModelCustomer(customer); add(new TextField(tf, model.bind(model.proxy ().getCustomerName() )).setRequired(true)); This way you can have it one one line. -Matej So proxy() returns a Customer proxy? And model.bind() takes an Object argument (considering we don't know in advance what type getCustomerName() returns)... What about primitive types? Overload bind() for those as well? Well, the return object is not important at all. What is important is the getCustomerName() call. That marks somewhere in the model that last accessed property was called customerName. and then immediately after this model.bind takes this information. OK, that's what I described. :-) And I was being stupid with respect to the overloading. If bind takes an object as argument, then overloading will not be necessary due to autoboxing. :-) And the call to getCustomerName() has the side effect of setting a model object somewhere (e.g., in an instance field of model) which model.bind() can subsequently return? Model bind will return a model (variation of propertymodel probably). It will take the information that getCustomerName call on proxy provided. Ok, so the proxy remembers which getter was called last, and you use that to construct the model in bind(). Of course. Very interesting. I don't like the proxy() method name though. If you call it something like property() it will look more like you're binding to a property of Customer: Well, the naming can certainly be improved. I'm not sure about property() though. Well, we can discuss this more anyway. model.bind(model.property().getCustomerName()) Neither am I. :-) For one, it's quite long. But on the other hand, you do bind to a model property, and so it reads ok. I think that proxies should be invisible for general users, so they shouldn't have to understand the magic going on here, nor that proxies are involved. VERY neat idea though... :-) Thanks. What I really like about this solution is that it can be implemented completely separately from wicket-core, so you can just put it in it's own project. :-) Regards, Sebastiaan -Matej Regards, Sebastiaan On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner [EMAIL PROTECTED] wrote: don't worry about creating the models That will happen anyway in 1.3 (that needs to be done for example to get the right object especially when we generify stuff) see CompoundPropertyModel.wrapOnInheritance() joan On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED] wrote: Interesting. So model.getFirstName() would return a PropetyModel based on the results of proxy.eval()? If I understand you correctly that creates many models (one per component) instead of reusing a single model, but that may well not be the end of the world. Or does getFirstName() return a CompoundModel that is properly bound this this component? Intriguing none the less. I hadn't considered this option, but I'm going to play with it a bit. I rather like that direction. On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED] wrote: i try to look at this this weekend, but i have a quick question I find it a bit verbose can't
Re: CompoundModel based on proxies
Have you tried this out using load testing? You are creating a new class every time you create a model. Have you run out of permgen space? On 2/26/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Well, there's a problem with normal PropertyModels (or CompoundPropertyModels). For example, if you have the following textfield: TextField tf = new TextField(name, new PropertyModel(customer, customerName)); Then a refactor of the customerName property (and the getCustomerName() method) in an IDE such as Eclipse or NetBeans will *silently* break the above code, which you will discover only at runtime... The proxy based approach solves exactly this problem. Regards, Sebastiaan atul singh wrote: I feel this approach does NOT solve a problem.Its just an alternative .. On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp [EMAIL PROTECTED] wrote: We've reworked the implementation a bit,it works like this: SafePropertyModelPerson p = new SafePropertyModelPerson(new Person()); TextField field = new TextField(name, p.bind(p.property ().getFirstName())); It's attached to the JIRA issue: https://issues.apache.org/jira/browse/WICKET-1327 -Matej On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: Hi, On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: model.getFirstName() can't really return IModel, if Customer.getFirstName() returns string. Anyway, I like the idea, but I don't like the syntax. instead of one line [add(new TextField(id, model).setRequred(true)) ] you have now three separate lines. So I was thinking of something more like SafePropertyModelCustomer model = new SafePropertyModelCustomer(customer); add(new TextField(tf, model.bind(model.proxy ().getCustomerName() )).setRequired(true)); This way you can have it one one line. -Matej So proxy() returns a Customer proxy? And model.bind() takes an Object argument (considering we don't know in advance what type getCustomerName() returns)... What about primitive types? Overload bind() for those as well? Well, the return object is not important at all. What is important is the getCustomerName() call. That marks somewhere in the model that last accessed property was called customerName. and then immediately after this model.bind takes this information. OK, that's what I described. :-) And I was being stupid with respect to the overloading. If bind takes an object as argument, then overloading will not be necessary due to autoboxing. :-) And the call to getCustomerName() has the side effect of setting a model object somewhere (e.g., in an instance field of model) which model.bind() can subsequently return? Model bind will return a model (variation of propertymodel probably). It will take the information that getCustomerName call on proxy provided. Ok, so the proxy remembers which getter was called last, and you use that to construct the model in bind(). Of course. Very interesting. I don't like the proxy() method name though. If you call it something like property() it will look more like you're binding to a property of Customer: Well, the naming can certainly be improved. I'm not sure about property() though. Well, we can discuss this more anyway. model.bind(model.property().getCustomerName()) Neither am I. :-) For one, it's quite long. But on the other hand, you do bind to a model property, and so it reads ok. I think that proxies should be invisible for general users, so they shouldn't have to understand the magic going on here, nor that proxies are involved. VERY neat idea though... :-) Thanks. What I really like about this solution is that it can be implemented completely separately from wicket-core, so you can just put it in it's own project. :-) Regards, Sebastiaan -Matej Regards, Sebastiaan On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner [EMAIL PROTECTED] wrote: don't worry about creating the models That will happen anyway in 1.3 (that needs to be done for example to get the right object especially when we generify stuff) see CompoundPropertyModel.wrapOnInheritance() joan On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED] wrote: Interesting. So model.getFirstName() would return a PropetyModel based on the results of proxy.eval()? If I understand you correctly that
Re: CompoundModel based on proxies
we can cache the created proxy class and simply give each instance a new handler... -igor On Tue, Feb 26, 2008 at 10:26 AM, James Carman [EMAIL PROTECTED] wrote: Have you tried this out using load testing? You are creating a new class every time you create a model. Have you run out of permgen space? On 2/26/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Well, there's a problem with normal PropertyModels (or CompoundPropertyModels). For example, if you have the following textfield: TextField tf = new TextField(name, new PropertyModel(customer, customerName)); Then a refactor of the customerName property (and the getCustomerName() method) in an IDE such as Eclipse or NetBeans will *silently* break the above code, which you will discover only at runtime... The proxy based approach solves exactly this problem. Regards, Sebastiaan atul singh wrote: I feel this approach does NOT solve a problem.Its just an alternative .. On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp [EMAIL PROTECTED] wrote: We've reworked the implementation a bit,it works like this: SafePropertyModelPerson p = new SafePropertyModelPerson(new Person()); TextField field = new TextField(name, p.bind(p.property ().getFirstName())); It's attached to the JIRA issue: https://issues.apache.org/jira/browse/WICKET-1327 -Matej On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: Hi, On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: model.getFirstName() can't really return IModel, if Customer.getFirstName() returns string. Anyway, I like the idea, but I don't like the syntax. instead of one line [add(new TextField(id, model).setRequred(true)) ] you have now three separate lines. So I was thinking of something more like SafePropertyModelCustomer model = new SafePropertyModelCustomer(customer); add(new TextField(tf, model.bind(model.proxy ().getCustomerName() )).setRequired(true)); This way you can have it one one line. -Matej So proxy() returns a Customer proxy? And model.bind() takes an Object argument (considering we don't know in advance what type getCustomerName() returns)... What about primitive types? Overload bind() for those as well? Well, the return object is not important at all. What is important is the getCustomerName() call. That marks somewhere in the model that last accessed property was called customerName. and then immediately after this model.bind takes this information. OK, that's what I described. :-) And I was being stupid with respect to the overloading. If bind takes an object as argument, then overloading will not be necessary due to autoboxing. :-) And the call to getCustomerName() has the side effect of setting a model object somewhere (e.g., in an instance field of model) which model.bind() can subsequently return? Model bind will return a model (variation of propertymodel probably). It will take the information that getCustomerName call on proxy provided. Ok, so the proxy remembers which getter was called last, and you use that to construct the model in bind(). Of course. Very interesting. I don't like the proxy() method name though. If you call it something like property() it will look more like you're binding to a property of Customer: Well, the naming can certainly be improved. I'm not sure about property() though. Well, we can discuss this more anyway. model.bind(model.property().getCustomerName()) Neither am I. :-) For one, it's quite long. But on the other hand, you do bind to a model property, and so it reads ok. I think that proxies should be invisible for general users, so they shouldn't have to understand the magic going on here, nor that proxies are involved. VERY neat idea though... :-) Thanks. What I really like about this solution is that it can be implemented completely separately from wicket-core, so you can just put it in it's own project. :-) Regards, Sebastiaan -Matej Regards, Sebastiaan On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner [EMAIL PROTECTED] wrote: don't worry about creating the models That will happen anyway in 1.3 (that needs to be done for
Re: CompoundModel based on proxies
So, you would cache the generated class (based on the type passed in) and then have it generate a new object each time. Then, cast that object to Factory and set its callbacks? On 2/26/08, Igor Vaynberg [EMAIL PROTECTED] wrote: we can cache the created proxy class and simply give each instance a new handler... -igor On Tue, Feb 26, 2008 at 10:26 AM, James Carman [EMAIL PROTECTED] wrote: Have you tried this out using load testing? You are creating a new class every time you create a model. Have you run out of permgen space? On 2/26/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Well, there's a problem with normal PropertyModels (or CompoundPropertyModels). For example, if you have the following textfield: TextField tf = new TextField(name, new PropertyModel(customer, customerName)); Then a refactor of the customerName property (and the getCustomerName() method) in an IDE such as Eclipse or NetBeans will *silently* break the above code, which you will discover only at runtime... The proxy based approach solves exactly this problem. Regards, Sebastiaan atul singh wrote: I feel this approach does NOT solve a problem.Its just an alternative .. On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp [EMAIL PROTECTED] wrote: We've reworked the implementation a bit,it works like this: SafePropertyModelPerson p = new SafePropertyModelPerson(new Person()); TextField field = new TextField(name, p.bind(p.property ().getFirstName())); It's attached to the JIRA issue: https://issues.apache.org/jira/browse/WICKET-1327 -Matej On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: Hi, On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: model.getFirstName() can't really return IModel, if Customer.getFirstName() returns string. Anyway, I like the idea, but I don't like the syntax. instead of one line [add(new TextField(id, model).setRequred(true)) ] you have now three separate lines. So I was thinking of something more like SafePropertyModelCustomer model = new SafePropertyModelCustomer(customer); add(new TextField(tf, model.bind(model.proxy ().getCustomerName() )).setRequired(true)); This way you can have it one one line. -Matej So proxy() returns a Customer proxy? And model.bind() takes an Object argument (considering we don't know in advance what type getCustomerName() returns)... What about primitive types? Overload bind() for those as well? Well, the return object is not important at all. What is important is the getCustomerName() call. That marks somewhere in the model that last accessed property was called customerName. and then immediately after this model.bind takes this information. OK, that's what I described. :-) And I was being stupid with respect to the overloading. If bind takes an object as argument, then overloading will not be necessary due to autoboxing. :-) And the call to getCustomerName() has the side effect of setting a model object somewhere (e.g., in an instance field of model) which model.bind() can subsequently return? Model bind will return a model (variation of propertymodel probably). It will take the information that getCustomerName call on proxy provided. Ok, so the proxy remembers which getter was called last, and you use that to construct the model in bind(). Of course. Very interesting. I don't like the proxy() method name though. If you call it something like property() it will look more like you're binding to a property of Customer: Well, the naming can certainly be improved. I'm not sure about property() though. Well, we can discuss this more anyway. model.bind(model.property().getCustomerName()) Neither am I. :-) For one, it's quite long. But on the other hand, you do bind to a model property, and so it reads ok. I think that proxies should be invisible for general users, so they shouldn't have to understand the magic going on here, nor that proxies are involved. VERY neat idea though... :-) Thanks. What I
Re: CompoundModel based on proxies
not really sure. but this is how it would work.
proxies in cglib take handlers. so you would do:
String key=modelclass.getname();
Class proxy=cache.get(key);
if (proxy==null) {
proxy=cglib.createproxy(modelclass);
cache.put(key,proxy);
}
proxyhandler handler=new proxyhandler(this);
Object instance=proxy.getconstructor(handler.class).newinstance(handler);
so we reuse the generated proxy class for all instances of the given
model class, and use a fresh handler to intercept all calls to proxy
and build the expression.
-igor
On Tue, Feb 26, 2008 at 10:36 AM, James Carman
[EMAIL PROTECTED] wrote:
So, you would cache the generated class (based on the type passed in)
and then have it generate a new object each time. Then, cast that
object to Factory and set its callbacks?
On 2/26/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
we can cache the created proxy class and simply give each instance a
new handler...
-igor
On Tue, Feb 26, 2008 at 10:26 AM, James Carman
[EMAIL PROTECTED] wrote:
Have you tried this out using load testing? You are creating a new
class every time you create a model. Have you run out of permgen
space?
On 2/26/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
Well, there's a problem with normal PropertyModels (or
CompoundPropertyModels).
For example, if you have the following textfield:
TextField tf = new TextField(name, new PropertyModel(customer,
customerName));
Then a refactor of the customerName property (and the
getCustomerName()
method) in an IDE such as Eclipse or NetBeans will *silently* break
the
above code, which you will discover only at runtime...
The proxy based approach solves exactly this problem.
Regards,
Sebastiaan
atul singh wrote:
I feel this approach does NOT solve a problem.Its just an
alternative ..
On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp [EMAIL PROTECTED]
wrote:
We've reworked the implementation a bit,it works like this:
SafePropertyModelPerson p = new SafePropertyModelPerson(new
Person());
TextField field = new TextField(name, p.bind(p.property
().getFirstName()));
It's attached to the JIRA issue:
https://issues.apache.org/jira/browse/WICKET-1327
-Matej
On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk
[EMAIL PROTECTED] wrote:
Matej Knopp wrote:
Hi,
On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk
[EMAIL PROTECTED] wrote:
Matej Knopp wrote:
model.getFirstName() can't really return IModel, if
Customer.getFirstName() returns string.
Anyway, I like the idea, but I don't like the syntax.
instead of
one
line [add(new TextField(id, model).setRequred(true)) ]
you have
now
three separate lines.
So I was thinking of something more like
SafePropertyModelCustomer model = new
SafePropertyModelCustomer(customer);
add(new TextField(tf, model.bind(model.proxy
().getCustomerName()
)).setRequired(true));
This way you can have it one one line.
-Matej
So proxy() returns a Customer proxy?
And model.bind() takes an Object argument (considering we
don't
know in
advance what type getCustomerName() returns)... What about
primitive
types? Overload bind() for those as well?
Well, the return object is not important at all. What is
important is
the getCustomerName() call. That marks somewhere in the
model that
last accessed property was called customerName. and then
immediately
after this model.bind takes this information.
OK, that's what I described. :-) And I was being stupid with
respect to
the overloading. If bind takes an object as argument, then
overloading
will not be necessary due to autoboxing. :-)
And the call to getCustomerName() has the side effect of
setting a
model
object somewhere (e.g., in an instance field of model)
which
model.bind() can subsequently return?
Model bind will return a model (variation of propertymodel
probably).
It will take the information that getCustomerName call on
proxy
provided.
Ok, so the proxy remembers which getter was called last, and
you use
that to construct the model in
Re: CompoundModel based on proxies
Well, if you wait a bit until I do another release of Commons Proxy,
it'll have that feature built in. Also, you could use Javassist if
you wanted to very easily.
On 2/26/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
not really sure. but this is how it would work.
proxies in cglib take handlers. so you would do:
String key=modelclass.getname();
Class proxy=cache.get(key);
if (proxy==null) {
proxy=cglib.createproxy(modelclass);
cache.put(key,proxy);
}
proxyhandler handler=new proxyhandler(this);
Object instance=proxy.getconstructor(handler.class).newinstance(handler);
so we reuse the generated proxy class for all instances of the given
model class, and use a fresh handler to intercept all calls to proxy
and build the expression.
-igor
On Tue, Feb 26, 2008 at 10:36 AM, James Carman
[EMAIL PROTECTED] wrote:
So, you would cache the generated class (based on the type passed in)
and then have it generate a new object each time. Then, cast that
object to Factory and set its callbacks?
On 2/26/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
we can cache the created proxy class and simply give each instance a
new handler...
-igor
On Tue, Feb 26, 2008 at 10:26 AM, James Carman
[EMAIL PROTECTED] wrote:
Have you tried this out using load testing? You are creating a new
class every time you create a model. Have you run out of permgen
space?
On 2/26/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
Well, there's a problem with normal PropertyModels (or
CompoundPropertyModels).
For example, if you have the following textfield:
TextField tf = new TextField(name, new PropertyModel(customer,
customerName));
Then a refactor of the customerName property (and the
getCustomerName()
method) in an IDE such as Eclipse or NetBeans will *silently*
break the
above code, which you will discover only at runtime...
The proxy based approach solves exactly this problem.
Regards,
Sebastiaan
atul singh wrote:
I feel this approach does NOT solve a problem.Its just an
alternative ..
On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp [EMAIL
PROTECTED] wrote:
We've reworked the implementation a bit,it works like this:
SafePropertyModelPerson p = new
SafePropertyModelPerson(new Person());
TextField field = new TextField(name, p.bind(p.property
().getFirstName()));
It's attached to the JIRA issue:
https://issues.apache.org/jira/browse/WICKET-1327
-Matej
On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk
[EMAIL PROTECTED] wrote:
Matej Knopp wrote:
Hi,
On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk
[EMAIL PROTECTED] wrote:
Matej Knopp wrote:
model.getFirstName() can't really return IModel, if
Customer.getFirstName() returns string.
Anyway, I like the idea, but I don't like the syntax.
instead of
one
line [add(new TextField(id,
model).setRequred(true)) ] you have
now
three separate lines.
So I was thinking of something more like
SafePropertyModelCustomer model = new
SafePropertyModelCustomer(customer);
add(new TextField(tf, model.bind(model.proxy
().getCustomerName()
)).setRequired(true));
This way you can have it one one line.
-Matej
So proxy() returns a Customer proxy?
And model.bind() takes an Object argument (considering
we don't
know in
advance what type getCustomerName() returns)... What
about
primitive
types? Overload bind() for those as well?
Well, the return object is not important at all. What is
important is
the getCustomerName() call. That marks somewhere in the
model that
last accessed property was called customerName. and then
immediately
after this model.bind takes this information.
OK, that's what I described. :-) And I was being stupid
with respect to
the overloading. If bind takes an object as argument, then
overloading
will not be necessary due to autoboxing. :-)
And the call to getCustomerName() has the side
Re: CompoundModel based on proxies
IntelliJ does a good job of locating String usages of property names
when you refactor a property name, which is nice. Not sure if
Eclipse/Netbeans do this also.
If you use CompoundPropertyModels then wouldn't refactoring your
business objects will still silently break code?
It seems that ideally you'd just reference a property by its name,
and continue using things like CompoundPropertyModel,
PropertyResolver, etc. which accept string representations of
properties. Using a code generation tool + generation gap pattern is
a good way to accomplish this for now, have the code generation
template generate String constants for all your property names in the
generated entity superclass java file.
All that said, this is a pretty nifty trick. I wonder how much it
will actually benefit developers, though.
-Sam
On Feb 26, 2008, at 10:43 AM, Igor Vaynberg wrote:
not really sure. but this is how it would work.
proxies in cglib take handlers. so you would do:
String key=modelclass.getname();
Class proxy=cache.get(key);
if (proxy==null) {
proxy=cglib.createproxy(modelclass);
cache.put(key,proxy);
}
proxyhandler handler=new proxyhandler(this);
Object instance=proxy.getconstructor(handler.class).newinstance
(handler);
so we reuse the generated proxy class for all instances of the given
model class, and use a fresh handler to intercept all calls to proxy
and build the expression.
-igor
On Tue, Feb 26, 2008 at 10:36 AM, James Carman
[EMAIL PROTECTED] wrote:
So, you would cache the generated class (based on the type passed in)
and then have it generate a new object each time. Then, cast that
object to Factory and set its callbacks?
On 2/26/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
we can cache the created proxy class and simply give each instance a
new handler...
-igor
On Tue, Feb 26, 2008 at 10:26 AM, James Carman
[EMAIL PROTECTED] wrote:
Have you tried this out using load testing? You are creating a new
class every time you create a model. Have you run out of permgen
space?
On 2/26/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
Well, there's a problem with normal PropertyModels (or
CompoundPropertyModels).
For example, if you have the following textfield:
TextField tf = new TextField(name, new PropertyModel(customer,
customerName));
Then a refactor of the customerName property (and the
getCustomerName()
method) in an IDE such as Eclipse or NetBeans will *silently*
break the
above code, which you will discover only at runtime...
The proxy based approach solves exactly this problem.
Regards,
Sebastiaan
atul singh wrote:
I feel this approach does NOT solve a problem.Its just an
alternative ..
On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp
[EMAIL PROTECTED] wrote:
We've reworked the implementation a bit,it works like this:
SafePropertyModelPerson p = new SafePropertyModelPerson
(new Person());
TextField field = new TextField(name, p.bind(p.property
().getFirstName()));
It's attached to the JIRA issue:
https://issues.apache.org/jira/browse/WICKET-1327
-Matej
On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk
[EMAIL PROTECTED] wrote:
Matej Knopp wrote:
Hi,
On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk
[EMAIL PROTECTED] wrote:
Matej Knopp wrote:
model.getFirstName() can't really return IModel, if
Customer.getFirstName() returns string.
Anyway, I like the idea, but I don't like the syntax.
instead of
one
line [add(new TextField(id, model).setRequred(true)) ]
you have
now
three separate lines.
So I was thinking of something more like
SafePropertyModelCustomer model = new
SafePropertyModelCustomer(customer);
add(new TextField(tf, model.bind(model.proxy
().getCustomerName()
)).setRequired(true));
This way you can have it one one line.
-Matej
So proxy() returns a Customer proxy?
And model.bind() takes an Object argument (considering we
don't
know in
advance what type getCustomerName() returns)... What about
primitive
types? Overload bind() for those as well?
Well, the return object is not important at all. What is
important is
the getCustomerName() call. That marks somewhere in the
model that
last accessed property was called customerName. and then
immediately
after this model.bind takes this information.
OK, that's what I described. :-) And I was being stupid
with respect to
the overloading. If bind takes an object as argument, then
overloading
will not be necessary due to autoboxing. :-)
And the call to getCustomerName() has the side effect of
setting a
model
object somewhere (e.g., in an instance field of model)
which
model.bind() can subsequently return?
Model bind will return a model (variation of propertymodel
probably).
It will take the information that getCustomerName call on
proxy
provided.
Ok, so the proxy remembers which getter was called last,
and you use
that to construct the model in bind(). Of course.
Very
Re: CompoundModel based on proxies
On 2/26/08, Igor Vaynberg [EMAIL PROTECTED] wrote: looking at commons-proxy we just need an invoker proxy. if you can do the caching behind the scenes for us that would be great. not sure what the code uses right now, cglib directly or something else. Commons Proxy allows you to swap out your implementation by coding to the ProxyFactory class. There are subclasses for CGLIB and Javassist right now. I'm implementing the changes now for CGLIB proxy class caching (all unit tests pass wonderfully yoo hoo). I was already doing it for Javassist. I didn't know how to do it before you said something about it just a minute ago. I wish I would have known before I cut the 1.0 release (just this past weekend). Oh well. And, yes, you would probably use an invoker to do what you want. -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
looking at commons-proxy we just need an invoker proxy. if you can do
the caching behind the scenes for us that would be great. not sure
what the code uses right now, cglib directly or something else.
-igor
On Tue, Feb 26, 2008 at 10:53 AM, James Carman
[EMAIL PROTECTED] wrote:
Well, if you wait a bit until I do another release of Commons Proxy,
it'll have that feature built in. Also, you could use Javassist if
you wanted to very easily.
On 2/26/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
not really sure. but this is how it would work.
proxies in cglib take handlers. so you would do:
String key=modelclass.getname();
Class proxy=cache.get(key);
if (proxy==null) {
proxy=cglib.createproxy(modelclass);
cache.put(key,proxy);
}
proxyhandler handler=new proxyhandler(this);
Object instance=proxy.getconstructor(handler.class).newinstance(handler);
so we reuse the generated proxy class for all instances of the given
model class, and use a fresh handler to intercept all calls to proxy
and build the expression.
-igor
On Tue, Feb 26, 2008 at 10:36 AM, James Carman
[EMAIL PROTECTED] wrote:
So, you would cache the generated class (based on the type passed in)
and then have it generate a new object each time. Then, cast that
object to Factory and set its callbacks?
On 2/26/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
we can cache the created proxy class and simply give each instance a
new handler...
-igor
On Tue, Feb 26, 2008 at 10:26 AM, James Carman
[EMAIL PROTECTED] wrote:
Have you tried this out using load testing? You are creating a
new
class every time you create a model. Have you run out of permgen
space?
On 2/26/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
Well, there's a problem with normal PropertyModels (or
CompoundPropertyModels).
For example, if you have the following textfield:
TextField tf = new TextField(name, new
PropertyModel(customer,
customerName));
Then a refactor of the customerName property (and the
getCustomerName()
method) in an IDE such as Eclipse or NetBeans will *silently*
break the
above code, which you will discover only at runtime...
The proxy based approach solves exactly this problem.
Regards,
Sebastiaan
atul singh wrote:
I feel this approach does NOT solve a problem.Its just
an alternative ..
On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp [EMAIL
PROTECTED] wrote:
We've reworked the implementation a bit,it works like this:
SafePropertyModelPerson p = new
SafePropertyModelPerson(new Person());
TextField field = new TextField(name, p.bind(p.property
().getFirstName()));
It's attached to the JIRA issue:
https://issues.apache.org/jira/browse/WICKET-1327
-Matej
On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk
[EMAIL PROTECTED] wrote:
Matej Knopp wrote:
Hi,
On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk
[EMAIL PROTECTED] wrote:
Matej Knopp wrote:
model.getFirstName() can't really return IModel, if
Customer.getFirstName() returns string.
Anyway, I like the idea, but I don't like the
syntax. instead of
one
line [add(new TextField(id,
model).setRequred(true)) ] you have
now
three separate lines.
So I was thinking of something more like
SafePropertyModelCustomer model = new
SafePropertyModelCustomer(customer);
add(new TextField(tf, model.bind(model.proxy
().getCustomerName()
)).setRequired(true));
This way you can have it one one line.
-Matej
So proxy() returns a Customer proxy?
And model.bind() takes an Object argument
(considering we don't
know in
advance what type getCustomerName() returns)... What
about
primitive
types? Overload bind() for those as well?
Well, the return object is not important at all. What
is important is
Re: CompoundModel based on proxies
I'm working on a non-trivial app that uses this model (we submitted it), and I like it. :) On Tue, Feb 26, 2008 at 11:00 AM, Sam Barnum [EMAIL PROTECTED] wrote: IntelliJ does a good job of locating String usages of property names when you refactor a property name, which is nice. Not sure if Eclipse/Netbeans do this also. If you use CompoundPropertyModels then wouldn't refactoring your business objects will still silently break code? It seems that ideally you'd just reference a property by its name, and continue using things like CompoundPropertyModel, PropertyResolver, etc. which accept string representations of properties. Using a code generation tool + generation gap pattern is a good way to accomplish this for now, have the code generation template generate String constants for all your property names in the generated entity superclass java file. All that said, this is a pretty nifty trick. I wonder how much it will actually benefit developers, though. -Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
Yes i would like to have something like commons proxy because i dont want if possible a direct dependency on cglib. It would be coool that we have a default impl that is based on jdk itself (so only interface support). Then drop in cglib and you have support for also classes On 2/26/08, James Carman [EMAIL PROTECTED] wrote: On 2/26/08, Igor Vaynberg [EMAIL PROTECTED] wrote: looking at commons-proxy we just need an invoker proxy. if you can do the caching behind the scenes for us that would be great. not sure what the code uses right now, cglib directly or something else. Commons Proxy allows you to swap out your implementation by coding to the ProxyFactory class. There are subclasses for CGLIB and Javassist right now. I'm implementing the changes now for CGLIB proxy class caching (all unit tests pass wonderfully yoo hoo). I was already doing it for Javassist. I didn't know how to do it before you said something about it just a minute ago. I wish I would have known before I cut the 1.0 release (just this past weekend). Oh well. And, yes, you would probably use an invoker to do what you want. -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
We dont serialize the expression builder see detach On 2/26/08, Scott Swank [EMAIL PROTECTED] wrote: I just added a relevant note about serialization (learned the hard way...) to the jira. - Scott On Tue, Feb 26, 2008 at 3:18 AM, Matej Knopp [EMAIL PROTECTED] wrote: We've reworked the implementation a bit,it works like this: SafePropertyModelPerson p = new SafePropertyModelPerson(new Person()); TextField field = new TextField(name, p.bind(p.property().getFirstName())); It's attached to the JIRA issue: https://issues.apache.org/jira/browse/WICKET-1327 -Matej - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
i try to look at this this weekend, but i have a quick question I find it a bit verbose can't it be a bit shorter like this (just an example) SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName, model.getFirstName()).setRequired(true); add(firstName); where getFirstName() returns the model johan On Feb 6, 2008 6:57 PM, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
don't worry about creating the models That will happen anyway in 1.3 (that needs to be done for example to get the right object especially when we generify stuff) see CompoundPropertyModel.wrapOnInheritance() joan On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED] wrote: Interesting. So model.getFirstName() would return a PropetyModel based on the results of proxy.eval()? If I understand you correctly that creates many models (one per component) instead of reusing a single model, but that may well not be the end of the world. Or does getFirstName() return a CompoundModel that is properly bound this this component? Intriguing none the less. I hadn't considered this option, but I'm going to play with it a bit. I rather like that direction. On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED] wrote: i try to look at this this weekend, but i have a quick question I find it a bit verbose can't it be a bit shorter like this (just an example) SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName, model.getFirstName()).setRequired(true); add(firstName); where getFirstName() returns the model johan On Feb 6, 2008 6:57 PM, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
Interesting. So model.getFirstName() would return a PropetyModel based on the results of proxy.eval()? If I understand you correctly that creates many models (one per component) instead of reusing a single model, but that may well not be the end of the world. Or does getFirstName() return a CompoundModel that is properly bound this this component? Intriguing none the less. I hadn't considered this option, but I'm going to play with it a bit. I rather like that direction. On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED] wrote: i try to look at this this weekend, but i have a quick question I find it a bit verbose can't it be a bit shorter like this (just an example) SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName, model.getFirstName()).setRequired(true); add(firstName); where getFirstName() returns the model johan On Feb 6, 2008 6:57 PM, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CompoundModel based on proxies
+ 1 for what Igor says. I remember debugging Hibernate code: you debug as far as your own code goes, and then you just guess. Oh, and yes: Tapestry anyone? Thomas -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Februar 2008 02:34 To: users@wicket.apache.org Subject: Re: CompoundModel based on proxies i disagree. i dont think we should be doing more with cglib in core or any other bytecode magic. have you ever tried to walk code that uses bytecode generation? its a nightmare. one of my favorite things about wicket is that it is just java and its easy as hell to debug. im not really against putting something like this into extensions, or even having a new wicket-bytecode/codegen/whatever package that contains things like these... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
The big argument for this cglib is to introduce some type safety to what is currently string-based bindings. This is a big plus. I don't think it's worth giving up the pure Java aspect that so many of us obviously like about Wicket. I'd rather see some IDE support that is smart about flagging bindings which refer to non-existent bean attributes. That way there's no magic or performance hit happening at runtime. IntelliJ does something similar for JPA query Strings. If a query references a non- existent property it appears as an error, even though they're just Strings. Obviously things get really sticky when you're dealing with CompoundPropertyModels, etc. Best case, of course, would be an addition to the java language that lets you refer to a property in a type-safe way. Is there a JSR for this? -Sam Barnum 360Works On Feb 7, 2008, at 1:50 AM, Maeder Thomas wrote: + 1 for what Igor says. I remember debugging Hibernate code: you debug as far as your own code goes, and then you just guess. Oh, and yes: Tapestry anyone? Thomas -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. Februar 2008 02:34 To: users@wicket.apache.org Subject: Re: CompoundModel based on proxies i disagree. i dont think we should be doing more with cglib in core or any other bytecode magic. have you ever tried to walk code that uses bytecode generation? its a nightmare. one of my favorite things about wicket is that it is just java and its easy as hell to debug. im not really against putting something like this into extensions, or even having a new wicket-bytecode/codegen/whatever package that contains things like these... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CompoundModel based on proxies
very nice! -Original Message- From: Scott Swank [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 12:57 PM To: Wicket User List Subject: CompoundModel based on proxies One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
Scott Swank wrote: We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. I'm quite interested in this. This looks like it is just crazy and clever enough to be really useful :-) Thanks! Carl-Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
please share for Wicket 1.4, if cglib's license is permitting, I think we should add this to core. Martijn On 2/6/08, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
if not cglib i can rewrite that with asm, its license is very liberal and we can even embed it into wicket - at least thats what ive done for salve to avoid version conflicts with other asm versions. -igor On Feb 6, 2008 1:04 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: please share for Wicket 1.4, if cglib's license is permitting, I think we should add this to core. Martijn On 2/6/08, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
The cglib website http://cglib.sourceforge.net/ points here for their license: http://www.apache.org/foundation/licence-FAQ.html So I don't think there are any issues. :) Are there any issues with attaching a zip file to an e-mail, or would you prefer another means? On Feb 6, 2008 1:06 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: if not cglib i can rewrite that with asm, its license is very liberal and we can even embed it into wicket - at least thats what ive done for salve to avoid version conflicts with other asm versions. -igor On Feb 6, 2008 1:04 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: please share for Wicket 1.4, if cglib's license is permitting, I think we should add this to core. Martijn On 2/6/08, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
I'm quite interested too. Daniel On 2008-02-06, at 19:27, Carl-Eric Menzel wrote: Scott Swank wrote: We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. I'm quite interested in this. This looks like it is just crazy and clever enough to be really useful :-) Thanks! Carl-Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
jira, that way you can click the im donating attachment to the project through ASL license checkbox -igor On Feb 6, 2008 1:10 PM, Scott Swank [EMAIL PROTECTED] wrote: The cglib website http://cglib.sourceforge.net/ points here for their license: http://www.apache.org/foundation/licence-FAQ.html So I don't think there are any issues. :) Are there any issues with attaching a zip file to an e-mail, or would you prefer another means? On Feb 6, 2008 1:06 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: if not cglib i can rewrite that with asm, its license is very liberal and we can even embed it into wicket - at least thats what ive done for salve to avoid version conflicts with other asm versions. -igor On Feb 6, 2008 1:04 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: please share for Wicket 1.4, if cglib's license is permitting, I think we should add this to core. Martijn On 2/6/08, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
https://issues.apache.org/jira/browse/WICKET-1327 On Feb 6, 2008 1:12 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: jira, that way you can click the im donating attachment to the project through ASL license checkbox -igor On Feb 6, 2008 1:10 PM, Scott Swank [EMAIL PROTECTED] wrote: The cglib website http://cglib.sourceforge.net/ points here for their license: http://www.apache.org/foundation/licence-FAQ.html So I don't think there are any issues. :) Are there any issues with attaching a zip file to an e-mail, or would you prefer another means? On Feb 6, 2008 1:06 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: if not cglib i can rewrite that with asm, its license is very liberal and we can even embed it into wicket - at least thats what ive done for salve to avoid version conflicts with other asm versions. -igor On Feb 6, 2008 1:04 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: please share for Wicket 1.4, if cglib's license is permitting, I think we should add this to core. Martijn On 2/6/08, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
Thanks! And I always thought: what happens in Vegas, stays in Vegas... Martijn On 2/6/08, Scott Swank [EMAIL PROTECTED] wrote: https://issues.apache.org/jira/browse/WICKET-1327 On Feb 6, 2008 1:12 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: jira, that way you can click the im donating attachment to the project through ASL license checkbox -igor On Feb 6, 2008 1:10 PM, Scott Swank [EMAIL PROTECTED] wrote: The cglib website http://cglib.sourceforge.net/ points here for their license: http://www.apache.org/foundation/licence-FAQ.html So I don't think there are any issues. :) Are there any issues with attaching a zip file to an e-mail, or would you prefer another means? On Feb 6, 2008 1:06 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: if not cglib i can rewrite that with asm, its license is very liberal and we can even embed it into wicket - at least thats what ive done for salve to avoid version conflicts with other asm versions. -igor On Feb 6, 2008 1:04 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: please share for Wicket 1.4, if cglib's license is permitting, I think we should add this to core. Martijn On 2/6/08, Scott Swank [EMAIL PROTECTED] wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
No problem. I didn't even write a line of it. :) On Feb 6, 2008 2:30 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: Thanks! And I always thought: what happens in Vegas, stays in Vegas... Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
On 2/7/08, Scott Swank [EMAIL PROTECTED] wrote: No problem. I didn't even write a line of it. :) Just for the record keeping: are you allowed to grant us the use of said model? Typically that should be done by the original copyright holder. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
I have his approval, but I can get him if you like. Let me know either way. On Feb 6, 2008 3:22 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: On 2/7/08, Scott Swank [EMAIL PROTECTED] wrote: No problem. I didn't even write a line of it. :) Just for the record keeping: are you allowed to grant us the use of said model? Typically that should be done by the original copyright holder. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
If he could leave a comment on the issue that would be great. If he has more ideas like this, get him to open a JIRA account :) Martijn On 2/7/08, Scott Swank [EMAIL PROTECTED] wrote: I have his approval, but I can get him if you like. Let me know either way. On Feb 6, 2008 3:22 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: On 2/7/08, Scott Swank [EMAIL PROTECTED] wrote: No problem. I didn't even write a line of it. :) Just for the record keeping: are you allowed to grant us the use of said model? Typically that should be done by the original copyright holder. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
like BoundCompoundPropertyModel, but safer. i think this almost might be too clever as it sacrifices some intuitiveness. also, it's filling in for a missing java feature. this should really be: boundModel.bind(component, firstName.property) (where .property, .field and .method are long-missing declarative reflections like .class) it does make me think we could be doing more with CGLIB in general. our model classes ought to be able to detect model changes better using proxies, for example. Scott Swank wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325663.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
another thing that occurs to me is that perhaps the method would be more generalized we basically made a fill-in for the missing .property feature. we could have a method like Reflection.property(expr) return a property expression string (or a compiled version of it). this makes me think there's a missing reflection package in java in general... Jonathan Locke wrote: like BoundCompoundPropertyModel, but safer. i think this almost might be too clever as it sacrifices some intuitiveness. also, it's filling in for a missing java feature. this should really be: boundModel.bind(component, firstName.property) (where .property, .field and .method are long-missing declarative reflections like .class) it does make me think we could be doing more with CGLIB in general. our model classes ought to be able to detect model changes better using proxies, for example. Scott Swank wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325688.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
i disagree. i dont think we should be doing more with cglib in core or any other bytecode magic. have you ever tried to walk code that uses bytecode generation? its a nightmare. one of my favorite things about wicket is that it is just java and its easy as hell to debug. im not really against putting something like this into extensions, or even having a new wicket-bytecode/codegen/whatever package that contains things like these... -igor On Feb 6, 2008 5:23 PM, Jonathan Locke [EMAIL PROTECTED] wrote: like BoundCompoundPropertyModel, but safer. i think this almost might be too clever as it sacrifices some intuitiveness. also, it's filling in for a missing java feature. this should really be: boundModel.bind(component, firstName.property) (where .property, .field and .method are long-missing declarative reflections like .class) it does make me think we could be doing more with CGLIB in general. our model classes ought to be able to detect model changes better using proxies, for example. Scott Swank wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325663.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
so you don't support this model then? igor.vaynberg wrote: i disagree. i dont think we should be doing more with cglib in core or any other bytecode magic. have you ever tried to walk code that uses bytecode generation? its a nightmare. one of my favorite things about wicket is that it is just java and its easy as hell to debug. im not really against putting something like this into extensions, or even having a new wicket-bytecode/codegen/whatever package that contains things like these... -igor On Feb 6, 2008 5:23 PM, Jonathan Locke [EMAIL PROTECTED] wrote: like BoundCompoundPropertyModel, but safer. i think this almost might be too clever as it sacrifices some intuitiveness. also, it's filling in for a missing java feature. this should really be: boundModel.bind(component, firstName.property) (where .property, .field and .method are long-missing declarative reflections like .class) it does make me think we could be doing more with CGLIB in general. our model classes ought to be able to detect model changes better using proxies, for example. Scott Swank wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325663.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325860.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
i support it in a non-core module -igor On Feb 6, 2008 5:41 PM, Jonathan Locke [EMAIL PROTECTED] wrote: so you don't support this model then? igor.vaynberg wrote: i disagree. i dont think we should be doing more with cglib in core or any other bytecode magic. have you ever tried to walk code that uses bytecode generation? its a nightmare. one of my favorite things about wicket is that it is just java and its easy as hell to debug. im not really against putting something like this into extensions, or even having a new wicket-bytecode/codegen/whatever package that contains things like these... -igor On Feb 6, 2008 5:23 PM, Jonathan Locke [EMAIL PROTECTED] wrote: like BoundCompoundPropertyModel, but safer. i think this almost might be too clever as it sacrifices some intuitiveness. also, it's filling in for a missing java feature. this should really be: boundModel.bind(component, firstName.property) (where .property, .field and .method are long-missing declarative reflections like .class) it does make me think we could be doing more with CGLIB in general. our model classes ought to be able to detect model changes better using proxies, for example. Scott Swank wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325663.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325860.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
There are additional considerations (at least in this implementation), all of which should be familiar to users of Hibernate or any proxy-based framework. 1) classes may not be final 2) methods may not be final 3) classes must have a no-method constructor Some folk may not be happy with these restrictions. - Scott On Feb 6, 2008 5:43 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: i support it in a non-core module -igor On Feb 6, 2008 5:41 PM, Jonathan Locke [EMAIL PROTECTED] wrote: so you don't support this model then? igor.vaynberg wrote: i disagree. i dont think we should be doing more with cglib in core or any other bytecode magic. have you ever tried to walk code that uses bytecode generation? its a nightmare. one of my favorite things about wicket is that it is just java and its easy as hell to debug. im not really against putting something like this into extensions, or even having a new wicket-bytecode/codegen/whatever package that contains things like these... -igor On Feb 6, 2008 5:23 PM, Jonathan Locke [EMAIL PROTECTED] wrote: like BoundCompoundPropertyModel, but safer. i think this almost might be too clever as it sacrifices some intuitiveness. also, it's filling in for a missing java feature. this should really be: boundModel.bind(component, firstName.property) (where .property, .field and .method are long-missing declarative reflections like .class) it does make me think we could be doing more with CGLIB in general. our model classes ought to be able to detect model changes better using proxies, for example. Scott Swank wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325663.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325860.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
If you're interested in using proxies, you could check out Apache Commons Proxy. It hasn't been released yet, but I would imagine we could get a release out the door in short order if it was wanted. The cool thing about ACP is that you can swap out the proxying technology easily (JDK proxies, CGLIB, and Javassist are currently supported). On 2/6/08, Igor Vaynberg [EMAIL PROTECTED] wrote: i support it in a non-core module -igor On Feb 6, 2008 5:41 PM, Jonathan Locke [EMAIL PROTECTED] wrote: so you don't support this model then? igor.vaynberg wrote: i disagree. i dont think we should be doing more with cglib in core or any other bytecode magic. have you ever tried to walk code that uses bytecode generation? its a nightmare. one of my favorite things about wicket is that it is just java and its easy as hell to debug. im not really against putting something like this into extensions, or even having a new wicket-bytecode/codegen/whatever package that contains things like these... -igor On Feb 6, 2008 5:23 PM, Jonathan Locke [EMAIL PROTECTED] wrote: like BoundCompoundPropertyModel, but safer. i think this almost might be too clever as it sacrifices some intuitiveness. also, it's filling in for a missing java feature. this should really be: boundModel.bind(component, firstName.property) (where .property, .field and .method are long-missing declarative reflections like .class) it does make me think we could be doing more with CGLIB in general. our model classes ought to be able to detect model changes better using proxies, for example. Scott Swank wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325663.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325860.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompoundModel based on proxies
makes sense to me. igor.vaynberg wrote: i support it in a non-core module -igor On Feb 6, 2008 5:41 PM, Jonathan Locke [EMAIL PROTECTED] wrote: so you don't support this model then? igor.vaynberg wrote: i disagree. i dont think we should be doing more with cglib in core or any other bytecode magic. have you ever tried to walk code that uses bytecode generation? its a nightmare. one of my favorite things about wicket is that it is just java and its easy as hell to debug. im not really against putting something like this into extensions, or even having a new wicket-bytecode/codegen/whatever package that contains things like these... -igor On Feb 6, 2008 5:23 PM, Jonathan Locke [EMAIL PROTECTED] wrote: like BoundCompoundPropertyModel, but safer. i think this almost might be too clever as it sacrifices some intuitiveness. also, it's filling in for a missing java feature. this should really be: boundModel.bind(component, firstName.property) (where .property, .field and .method are long-missing declarative reflections like .class) it does make me think we could be doing more with CGLIB in general. our model classes ought to be able to detect model changes better using proxies, for example. Scott Swank wrote: One of our more clever developers created a CompoundPropertyModel that uses a cglib proxy to strongly bind the mutators to the model. It looks like this: SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName).setRequired(true); model.bind(firstName).to().getFirstName(); add(firstName); FormComponent lastName = new CustomerNameField(lastName).setRequired(true); model.bind(lastName).to().getLastName(); add(lastName); FormComponent addr1 = new AddressField(address1).setRequired(true); model.bind(addr1).to().getAddress().getAddress1(); add(addr1); FormComponent addr2 = new AddressField(address2); model.bind(addr2).to().getAddress().getAddress2(); add(addr2); FormComponent city = new CityField(city); model.bind(city).to().getAddress().getCity(); add(city); We're happy to share if folk like this approach. N.B. that the .to() call is for readability rather than out of any necessity. Cheers, Scott -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325663.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325860.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CompoundModel-based-on-proxies-tp15317807p15325972.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
