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 -
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
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
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
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
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());
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
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
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
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
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)
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
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.
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
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
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
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
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
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
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
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
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
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.
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
@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
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
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
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
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
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
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,
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
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:
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
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
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:
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:
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
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
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
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
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
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
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
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
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,
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
78 matches
Mail list logo
