After rechecking the whole thread, I couldn't find out if this change got into the 1.1 release. Can
somebdoy put some light onto this?
thanks a lot,
./alex
--
.w( the_mindstorm )p.
#: Johan Compagner changed the world a bit at a time by saying on 10/27/2005
1:41 AM :#
Hi
I have written a
no this is 1.2On 11/10/05, Alexandru Popescu [EMAIL PROTECTED] wrote:
After rechecking the whole thread, I couldn't find out if this change got into the 1.1
release. Cansomebdoy put some light onto this?thanks a lot,./alex--.w( the_mindstorm )p.#: Johan Compagner changed the world a bit at a time
#: Johan Compagner changed the world a bit at a time by saying on 11/10/2005
2:05 AM :#
no this is 1.2
Thanks Johan.
./alex
--
.w( the_mindstorm )p.
On 11/10/05, Alexandru Popescu [EMAIL PROTECTED] wrote:
After rechecking the whole thread, I couldn't find out if this change got
into
Conversion is first done in Wicket itself.
So if you have a Field that gets its value from a map then you just have to type youre field first:
TextField datePropertyTextField = new TextField(map.property, Date.class);
I already thought about looking at the current key/index and then convert it
I have tried CVS HEAD, but my old codes which based on ognl is broken since I use foo.bar.baz syntax to access public field.
I hope that we are not restricted to only getter/setter:
private String myProperty
public String getMyProperty()
public void setMyProperty()
but also support :
public
This is being fixed (as I read on the dev list).
Martijn
On 11/1/05, Ingram Chen [EMAIL PROTECTED] wrote:
I have tried CVS HEAD, but my old codes which based on ognl is broken since
I use foo.bar.baz syntax to access public field.
I hope that we are not restricted to only getter/setter:
In my opinion, there's no need for another indirection. From what I've
seen, new users are already confused about models, making them even more
complicated isn't imho the way to go.
I think that Ognl models should be separated from the core and put to
extensions. That would also get rid of
I agree with Matej.
Eelco
On 10/30/05, Matej Knopp [EMAIL PROTECTED] wrote:
In my opinion, there's no need for another indirection. From what I've
seen, new users are already confused about models, making them even more
complicated isn't imho the way to go.
I think that Ognl models should
yes i think having a switch globally is not a good use case.
I think you just have to choose it at model level. The only problem is that i have changed
AbstractPropertyModel. And that one is the base class for X numbmer of classes (like compound)
So the only real solution (besides always have at
Does Wicket also check for direct public property of the same name ?
not yet, but that is easy to build.
Same remark concerning maps vs beans.If find it great if we don't know if the property is contained in the
Map or is a property of the Model.
i am alos still in favor the current impl by
On 10/28/05, Johan Compagner [EMAIL PROTECTED] wrote:
Does Wicket also check for direct public property of the same name ?
not yet, but that is easy to build.
That would be great.
Same remark concerning maps vs beans.
If find it great if we don't know if the property is contained in
don't know if that is weird (that the key is not there)
it can be completely valid.
What happens if i do this:
map.xxx = yyy
First i try to get xxx key?
Not there then i try to get xxx as a property
still not there the back to the map?
i still think that i can first check for the _expression_
Well, yes,
in fact, I think we can guess that it would be dangereous an error
prone for the developer to have a key of the map with the same name as
the property.
So, indeed, it is not a problem if you first check for the property,
then the map value.
+1 for that,
--
Laurent
On 10/28/05,
On 10/27/05, Johan Compagner [EMAIL PROTECTED] wrote:
That NPE is already handled.
When you do a get a and somewhere in the line a null is encountered then
null is returned
Great!!!
I still am thinking of a way to create the null object then this can be
automatic if the object
i have
I like the idea of being able to plug in OGNL if you really need it.
Now that I think about it, I've got a couple ChoiceRenderers that call
functions using OGNL. Although, it probably would be very easy to
rewrite these by just implementing the interface myself, and much more
efficient.
#: Martijn Dashorst changed the world a bit at a time by saying on 10/27/2005
7:28 AM :#
+1 on moving OGNL into extensions.
I think the OGNL thing is good, it provides a nice base
implementation. I'd like to see the current implementation still being
available for those 1% that need the full
I'm also +1 on moving OGNL into extension
I guess this is: person.children.[0].name and Johan already mentioned it.
I think Johan mentioned, it'll be person.children.0.name
Juergen
On 10/27/05, Alexandru Popescu [EMAIL PROTECTED] wrote:
#: Martijn Dashorst changed the world a bit at a time
2005 7:28
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] replace ognl.
+1 on moving OGNL into extensions.
I think the OGNL thing is good, it provides a nice base
implementation. I'd like to see the current implementation still being
available for those 1% that need the full OGNL
yes i currently don't have support for { or [ or things like that.
Just plain text with dots. This makes it very easy and fast to parse.
but if people really want this:
person.children[0].name
does ognl has a special map _expression_? something like person.childeren{child1}.name ?
i know that it
Yes, I agree. Keep it simple. Doesn't Groovy do it the same way, you
proposed it, Johan?
Juergen
On 10/27/05, Alexandru Popescu [EMAIL PROTECTED] wrote:
#: Johan Compagner changed the world a bit at a time by saying on 10/27/2005
10:06 AM :#
yes i currently don't have support for { or [ or
I strongly support replacing OGNL with something more performant, as
long as it is not yet another new syntax for accessing properties (we
already have OGNL, Spring property access syntax, some expression
languages from the JSP/Taglib world and probably some others). At
least it sould be OGNL
That NPE is already handled.
When you do a get a and somewhere in the line a null is encountered then null is returned
With a set a NPE is thrown currently because if that is not handled you loose data (which is bad)
I still am thinking of a way to create the null object then this can be
a NullPropertyHandler.
./alex
--
.w( the_mindstorm )p.
Maurice Marrink
www.topicus.nl
-Original Message-
From: Felix von Delius [mailto:[EMAIL PROTECTED]
Sent: donderdag 27 oktober 2005 11:10
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] replace
Message- From: Felix von Delius [mailto:[EMAIL PROTECTED]
] Sent: donderdag 27 oktober 2005 11:10 To: wicket-user@lists.sourceforge.net Subject: Re: [Wicket-user] replace ognl. I strongly support replacing OGNL with something more performant, as
long as it is not yet another new syntax
I'm also +1 for replacing ognl.
I'm not trying to say that Wicket is slow, not at all, but any speed
improvement is .an improvement :)!
- Johannes
Johan Compagner wrote:
Hi
I have written a replacement of OGNL when i test it with a very simple
test (The FormInput example)
then i see
Johan Compagner wrote:
yes i currently don't have support for { or [ or things like that.
Just plain text with dots. This makes it very easy and fast to parse.
but if people really want this:
person.children[0].name
I can think of two reasons why an access operator [] could be useful:
- It
I can think of two reasons why an access operator [] could be useful:- It might make the _expression_ more readable, because you know that you
are operating on an array, List or Map by looking at the _expression_.- The content of the access operator could be an _expression_ itself.
Johan Compagner wrote:
I can think of two reasons why an access operator [] could be useful:
- It might make the expression more readable, because you know that you
are operating on an array, List or Map by looking at the expression.
- The content of the access operator could be an expression
I'm not too sure about using dots for index/ map references. It
differs from OGNL:
http://www.ognl.org/2.6.7/Documentation/html/LanguageGuide/indexing.html.
And personally, I think it is usefull to be able to distinct single
from indexed properties just by looking at the expression. Is it
/that/
ognl can do map lookup with just a _expression_
(that was the first thing i had to do because that did go wrong when i started testing it)
this was used: Ognl.getValue(string, anHashmap);
so the need to do [sd] even with juk why is that needed ...?
On 10/27/05, Eelco Hillenius [EMAIL PROTECTED]
If it equals at least one of the OGNL uses, then I'm fine with it.
Eelco
On 10/27/05, Johan Compagner [EMAIL PROTECTED] wrote:
ognl can do map lookup with just a expression
(that was the first thing i had to do because that did go wrong when i
started testing it)
this was used:
The only thing for me to use [] for an index and { } for a map (for example)
would be that this:
mymap.property would mean that you really want to have a getProperty on a map
(same goes for list)
so i will change it to use with [] (without quotes that i find totally not needed)
foo.list[0].bar
I'd prefer if it used a groovy-like syntax (or actual groovy behind the
curtain) as much as possible.
[EMAIL PROTECTED] 2005-10-27 11:15:05 AM
The only thing for me to use [] for an index and { } for a map (for
example)
would be that this:
mymap.property would mean that you really want to
Johan Compagner wrote:
The only thing for me to use [] for an index and { } for a map (for example)
would be that this:
mymap.property would mean that you really want to have a getProperty on
a map
(same goes for list)
so i will change it to use with [] (without quotes that i find totally
and that is?
Very similar to what you are proposing:
http://groovy.codehaus.org/Collections
and
bean?.property (allows bean to be null)
(see http://groovy.codehaus.org/Migration+From+Classic+to+JSR+syntax )
I really appreciate how OGNL is very flexible with allowing me to do
things
PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Carlson
Sent: Thursday, October 27, 2005 11:40 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] replace ognl.
and that is?
Very similar to what you are proposing:
http://groovy.codehaus.org/Collections
It's all about choice of course. I agree with most proponents of
getting rid of OGNL: it's way too heavy for 95% (or more) of the usual
cases, and less dependencies == good. But, I think it would be really
good not only to keep alternatives in e.g. the extensions project, or
with a seperate
Oh, and of course AbstractPropertyModel.ognlExpression should be
replaced by e.g. .expression or something similar.
Eelco
---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free
Hello all,
This is my very first post on this list. Glad to being able to
exchange ideas with you.
On 10/27/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
Why not keep wicket simple? I really like the simplicity of the dot notation
johan created. I think we should use [] only as a hint.
By
Hello,
On 10/27/05, Eelco Hillenius [EMAIL PROTECTED] wrote:
AbstractPropertyModel could work with something like a
propertyresolver/ delegate (one more indirection :)) for getting and
setting values based on a expression, and it might even be a good idea
to have the option of having the
Yeah, that's true. You're right. Maybe it isn't such a good idea then.
Eelco
On 10/27/05, Laurent PETIT [EMAIL PROTECTED] wrote:
Hello,
On 10/27/05, Eelco Hillenius [EMAIL PROTECTED] wrote:
AbstractPropertyModel could work with something like a
propertyresolver/ delegate (one more
sounds awesome, great job Johan!
Im +1 for dropping ognl, you covered all my
usecases.
-Igor
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Johan
CompagnerSent: Wednesday, October 26, 2005 4:41 PMTo:
wicket-user@lists.sourceforge.netSubject: [Wicket-user]
I vote to get rid of OGNL too. I know that the Spring Framework
MVC uses its own home grown one as well and it has worked perfectly for
every use case I've ever had.
--AndrewOn 10/26/05, Alexandru Popescu [EMAIL PROTECTED] wrote:
#: Johan Compagner changed the world a bit at a time by saying
Please don't get the impression I haven't believed you; I was just wondering.
My opinion on this matter is according to make simple things easy, and complex
things possible.
I am not aware of how this part is currently implemented, but I guess the best approach would be a
value retrieval
: [Wicket-user] replace ognl.
Please don't get the impression I haven't believed you; I was
just wondering.
My opinion on this matter is according to make simple things
easy, and complex things possible.
I am not aware of how this part is currently implemented, but
I guess the best approach
+1
but... I believe that introduceing new syntax of _expression_ language make Wicket
hard to learn, especially for those developers with JSP/JSTL background (most of us !)
It's better if we can reuse EL (_expression_ language) syntax, a J2EE standard, for new
implmentation.
On 10/27/05, Johan
+1 on moving OGNL into extensions.
I think the OGNL thing is good, it provides a nice base
implementation. I'd like to see the current implementation still being
available for those 1% that need the full OGNL expression evaluator
(though I think I share the same sentiment Phil voiced).
Do we
47 matches
Mail list logo
