Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-04-14 06:48:57
|
Karl,
=20
Agreed, it makes sense to be consistent with Commons BeanUtils / Commons =
Validator / Struts here, while still supporting the current syntax. Our =
current syntax is somewhat analogous to JSTL EL, but I don't mind =
supporting further syntactic options, as long as they don't introduce =
parsing problems.
=20
This should be pretty trivial to add, so I'll look into it this weekend.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Baum, Karl
Gesendet: Mi 14.04.2004 04:19
An: spr...@li...
Betreff: [Springframework-developer] java.util.Map fields and commons =
validator
I have encountered an issue in regards to validating beans backed by a
Map object while using the spring commons validator component. My form
is made to work with key value pairsbacked as a map. It has a field:
/**
* @return
*/
public Map getValue() {
return valueMap;
}
/**
* @param map
*/
public void setValue(Map map) {
valueMap =3D map;
}
The problem isn't specific to the validator adapter. The problem has to
do with the way Spring symbolizes a mapped property in the
BeanwrapperImpl class. Spring uses a '[' where as commons validator and
struts use '('. Another words a mapped property of firstName would look
like this in Spring:
value[firstName]
and this in commons validator:
value(firstName)
Commons validator uses '[' for indexed properties. Spring uses '[' for
both indexed and Mapped properties. I think the best place to fix this
problem is on the Spring side in the BeanWrapperImpl. We might as well
be consistent with struts and commons validator in regards to our
indexed and mapped property sytax. Perhaps we can support both
syntaxes.=20
Any thoughts?
Karl
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2004-04-18 18:40:29
|
On reflection, I agree: Introducing alternative "(" syntax would =
probably cause more harm than benefit in the long term. I'll leave the =
current syntax as-is.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Peter den Haan
Gesendet: Mi 14.04.2004 21:11
An: spr...@li...
Betreff: Re: [lists] Re: [Springframework-developer] java.util.Map =
fields and commons validator
Colin Sampaleanu wrote:
> The existing spring approach is also similar to OGNL. In OGNL, '(' is
> used for an actual method call [...] It would make the validation =
usage
> a bit more similar to commons-validator/struts, but would muddy the
> water for general expression syntax.
Indeed; at some point we might want to support OGNL-like method =
invocations
and we would have made the expression language a lot more difficult to
parse, implement and also to read. Of course the JSP EL also supports
function invocations, using the foo:bar() syntax. Supporting a =
property(foo)
syntax might end up being a liability rather than an asset.
- Peter
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Hunter K. <re...@ei...> - 2004-04-14 09:34:43
|
I have to say that I personally prefer [] syntax for both indexed and map=
ped
properties, it's a more natural fit with scripting languages, and to me i=
t
just makes more sense - it's an indexing operation, not a method call!
My point is that it'd be great to support other syntaxes, but please
keep the [ syntax.
H
On Wednesday 14 April 2004 07:44, j=FCrgen h=F6ller [werk3AT] wrote:
> Karl,
>
> Agreed, it makes sense to be consistent with Commons BeanUtils / Common=
s
> Validator / Struts here, while still supporting the current syntax. Our
> current syntax is somewhat analogous to JSTL EL, but I don't mind
> supporting further syntactic options, as long as they don't introduce
> parsing problems.
>
> This should be pretty trivial to add, so I'll look into it this weekend.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag v=
on
> Baum, Karl Gesendet: Mi 14.04.2004 04:19
> An: spr...@li...
> Betreff: [Springframework-developer] java.util.Map fields and commons
> validator
>
>
>
> I have encountered an issue in regards to validating beans backed by a
> Map object while using the spring commons validator component. My form
> is made to work with key value pairsbacked as a map. It has a field:
>
> /**
> * @return
> */
> public Map getValue() {
> return valueMap;
> }
>
> /**
> * @param map
> */
> public void setValue(Map map) {
> valueMap =3D map;
> }
>
> The problem isn't specific to the validator adapter. The problem has t=
o
> do with the way Spring symbolizes a mapped property in the
> BeanwrapperImpl class. Spring uses a '[' where as commons validator an=
d
> struts use '('. Another words a mapped property of firstName would loo=
k
> like this in Spring:
>
> value[firstName]
>
> and this in commons validator:
>
> value(firstName)
>
> Commons validator uses '[' for indexed properties. Spring uses '[' for
> both indexed and Mapped properties. I think the best place to fix this
> problem is on the Spring side in the BeanWrapperImpl. We might as well
> be consistent with struts and commons validator in regards to our
> indexed and mapped property sytax. Perhaps we can support both
> syntaxes.
>
> Any thoughts?
>
> Karl
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3DClick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Baum, K. <Kar...@Ta...> - 2004-04-14 12:43:51
|
There is one other slight issue I noticed with mapped properties. In
addition to supporting get/set methods that work with a Map object,
Struts suports methods that take key value pairs. For example:
public void setValue(String key, String value);
public String getValue(String key);
This feature allows the developer to abstract the underlying
implementation. It also guards against external code overwriting your
Map. Spring does not support this because it only uses java bean
introspection to find all properties in a bean. These Map methods are
not properties to Java. =20
I think in addition to supporting all get/sets picked up by the Bean
Introspecter, we should consider supporting this other get/set syntax
for Mapped properties.
=20
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On =
Behalf
Of Hunter Kelly
Sent: Wednesday, April 14, 2004 5:35 AM
To: spr...@li...
Subject: Re: [Springframework-developer] java.util.Map fields and
commons validator
I have to say that I personally prefer [] syntax for both indexed and
mapped
properties, it's a more natural fit with scripting languages, and to me
it
just makes more sense - it's an indexing operation, not a method call!
My point is that it'd be great to support other syntaxes, but please
keep the [ syntax.
H
On Wednesday 14 April 2004 07:44, j=FCrgen h=F6ller [werk3AT] wrote:
> Karl,
>
> Agreed, it makes sense to be consistent with Commons BeanUtils /
Commons
> Validator / Struts here, while still supporting the current syntax.
Our
> current syntax is somewhat analogous to JSTL EL, but I don't mind
> supporting further syntactic options, as long as they don't introduce
> parsing problems.
>
> This should be pretty trivial to add, so I'll look into it this
weekend.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag
von
> Baum, Karl Gesendet: Mi 14.04.2004 04:19
> An: spr...@li...
> Betreff: [Springframework-developer] java.util.Map fields and commons
> validator
>
>
>
> I have encountered an issue in regards to validating beans backed by =
a
> Map object while using the spring commons validator component. My
form
> is made to work with key value pairsbacked as a map. It has a field:
>
> /**
> * @return
> */
> public Map getValue() {
> return valueMap;
> }
>
> /**
> * @param map
> */
> public void setValue(Map map) {
> valueMap =3D map;
> }
>
> The problem isn't specific to the validator adapter. The problem has
to
> do with the way Spring symbolizes a mapped property in the
> BeanwrapperImpl class. Spring uses a '[' where as commons validator
and
> struts use '('. Another words a mapped property of firstName would
look
> like this in Spring:
>
> value[firstName]
>
> and this in commons validator:
>
> value(firstName)
>
> Commons validator uses '[' for indexed properties. Spring uses '['
for
> both indexed and Mapped properties. I think the best place to fix
this
> problem is on the Spring side in the BeanWrapperImpl. We might as
well
> be consistent with struts and commons validator in regards to our
> indexed and mapped property sytax. Perhaps we can support both
> syntaxes.
>
> Any thoughts?
>
> Karl
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3DClick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Seth L. <se...@eh...> - 2004-04-14 18:47:59
|
Baum, Karl wrote:
> There is one other slight issue I noticed with mapped properties. In
> addition to supporting get/set methods that work with a Map object,
> Struts suports methods that take key value pairs. For example:
>
> public void setValue(String key, String value);
>
> public String getValue(String key);
>
> This feature allows the developer to abstract the underlying
> implementation. It also guards against external code overwriting your
> Map. Spring does not support this because it only uses java bean
> introspection to find all properties in a bean. These Map methods are
> not properties to Java.
Just MHO, but I never liked that above Struts idiom. It's easy to think
about objects as object graphs and beans. To me, the above breaks that
simple object graph notation. If what I'm trying to say is "object foo
has a Map called bar" then the above way doesn't say that very clearly.
Here's where I think Spring does a better job than Struts in mapping
properties and objects together. Also, I'm -1 on adding then '('
support. While I am sympathetic (I, too, am migrating Struts apps to
Spring MVC) I'd like to take steps forward, not just simply port. I
think the more standard '[' makes more sense.
Seth
|
|
From: Keith D. <kd...@cs...> - 2004-04-14 13:26:59
|
Yes, the [] syntax makes much more sense. That's what OGNL uses, too (wh=
ich
means WebWork, Tapestry.)
Keith
----- Original Message -----=20
From: "Hunter Kelly" <re...@ei...>
To: <spr...@li...>
Sent: Wednesday, April 14, 2004 5:34 AM
Subject: Re: [Springframework-developer] java.util.Map fields and commons
validator
> I have to say that I personally prefer [] syntax for both indexed and
mapped
> properties, it's a more natural fit with scripting languages, and to me=
it
> just makes more sense - it's an indexing operation, not a method call!
>
> My point is that it'd be great to support other syntaxes, but please
> keep the [ syntax.
>
> H
>
> On Wednesday 14 April 2004 07:44, j=FCrgen h=F6ller [werk3AT] wrote:
> > Karl,
> >
> > Agreed, it makes sense to be consistent with Commons BeanUtils / Comm=
ons
> > Validator / Struts here, while still supporting the current syntax. O=
ur
> > current syntax is somewhat analogous to JSTL EL, but I don't mind
> > supporting further syntactic options, as long as they don't introduce
> > parsing problems.
> >
> > This should be pretty trivial to add, so I'll look into it this weeke=
nd.
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li... im Auftrag
von
> > Baum, Karl Gesendet: Mi 14.04.2004 04:19
> > An: spr...@li...
> > Betreff: [Springframework-developer] java.util.Map fields and commons
> > validator
> >
> >
> >
> > I have encountered an issue in regards to validating beans backed by =
a
> > Map object while using the spring commons validator component. My fo=
rm
> > is made to work with key value pairsbacked as a map. It has a field:
> >
> > /**
> > * @return
> > */
> > public Map getValue() {
> > return valueMap;
> > }
> >
> > /**
> > * @param map
> > */
> > public void setValue(Map map) {
> > valueMap =3D map;
> > }
> >
> > The problem isn't specific to the validator adapter. The problem has=
to
> > do with the way Spring symbolizes a mapped property in the
> > BeanwrapperImpl class. Spring uses a '[' where as commons validator =
and
> > struts use '('. Another words a mapped property of firstName would l=
ook
> > like this in Spring:
> >
> > value[firstName]
> >
> > and this in commons validator:
> >
> > value(firstName)
> >
> > Commons validator uses '[' for indexed properties. Spring uses '[' f=
or
> > both indexed and Mapped properties. I think the best place to fix th=
is
> > problem is on the Spring side in the BeanWrapperImpl. We might as we=
ll
> > be consistent with struts and commons validator in regards to our
> > indexed and mapped property sytax. Perhaps we can support both
> > syntaxes.
> >
> > Any thoughts?
> >
> > Karl
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3D=
click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-develope=
r
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3DClick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-develope=
r
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Colin S. <col...@ex...> - 2004-04-14 11:54:02
|
The existing spring approach is also similar to OGNL. In OGNL, '(' is
used for an actual method call, since you can also call methods, not
just navigate graphs.
I'm a bit of mixed feelings about adding '(' support in the BeanWrapper.
It would make the validation usage a bit more similar to
commons-validator/struts, but would muddy the water for general
expression syntax.
Karl, your issue with the setup right now is that people can't take
their existing definitions exactly as-is?
jürgen höller [werk3AT] wrote:
>Karl,
>
>Agreed, it makes sense to be consistent with Commons BeanUtils / Commons Validator / Struts here, while still supporting the current syntax. Our current syntax is somewhat analogous to JSTL EL, but I don't mind supporting further syntactic options, as long as they don't introduce parsing problems.
>
>This should be pretty trivial to add, so I'll look into it this weekend.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von Baum, Karl
>Gesendet: Mi 14.04.2004 04:19
>An: spr...@li...
>Betreff: [Springframework-developer] java.util.Map fields and commons validator
>
>
>
>I have encountered an issue in regards to validating beans backed by a
>Map object while using the spring commons validator component. My form
>is made to work with key value pairsbacked as a map. It has a field:
>
> /**
> * @return
> */
> public Map getValue() {
> return valueMap;
> }
>
> /**
> * @param map
> */
> public void setValue(Map map) {
> valueMap = map;
> }
>
>The problem isn't specific to the validator adapter. The problem has to
>do with the way Spring symbolizes a mapped property in the
>BeanwrapperImpl class. Spring uses a '[' where as commons validator and
>struts use '('. Another words a mapped property of firstName would look
>like this in Spring:
>
> value[firstName]
>
>and this in commons validator:
>
> value(firstName)
>
>Commons validator uses '[' for indexed properties. Spring uses '[' for
>both indexed and Mapped properties. I think the best place to fix this
>problem is on the Spring side in the BeanWrapperImpl. We might as well
>be consistent with struts and commons validator in regards to our
>indexed and mapped property sytax. Perhaps we can support both
>syntaxes.
>
>Any thoughts?
>
>Karl
>
>
|
|
From: Baum, K. <Kar...@Ta...> - 2004-04-14 14:09:11
|
My issue is more with compatibility between commons validator and
spring. Currently today, to denote a mapped property in spring we use
the '[' character. However when this is sent to commons validator, it
will not be able to find this property in the bean as it will be =
looking
for an indexed property as opposed to a mapped property.
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On =
Behalf
Of Colin Sampaleanu
Sent: Wednesday, April 14, 2004 7:57 AM
To: spr...@li...
Subject: Re: [Springframework-developer] java.util.Map fields and
commons validator
The existing spring approach is also similar to OGNL. In OGNL, '(' is=20
used for an actual method call, since you can also call methods, not=20
just navigate graphs.
I'm a bit of mixed feelings about adding '(' support in the =
BeanWrapper.
It would make the validation usage a bit more similar to=20
commons-validator/struts, but would muddy the water for general=20
expression syntax.
Karl, your issue with the setup right now is that people can't take=20
their existing definitions exactly as-is?
j=FCrgen h=F6ller [werk3AT] wrote:
>Karl,
>=20
>Agreed, it makes sense to be consistent with Commons BeanUtils /
Commons Validator / Struts here, while still supporting the current
syntax. Our current syntax is somewhat analogous to JSTL EL, but I =
don't
mind supporting further syntactic options, as long as they don't
introduce parsing problems.
>=20
>This should be pretty trivial to add, so I'll look into it this
weekend.
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag
von Baum, Karl
>Gesendet: Mi 14.04.2004 04:19
>An: spr...@li...
>Betreff: [Springframework-developer] java.util.Map fields and commons
validator
>
>
>
>I have encountered an issue in regards to validating beans backed by a
>Map object while using the spring commons validator component. My =
form
>is made to work with key value pairsbacked as a map. It has a field:
>
> /**
> * @return
> */
> public Map getValue() {
> return valueMap;
> }
>
> /**
> * @param map
> */
> public void setValue(Map map) {
> valueMap =3D map;
> }
>
>The problem isn't specific to the validator adapter. The problem has
to
>do with the way Spring symbolizes a mapped property in the
>BeanwrapperImpl class. Spring uses a '[' where as commons validator
and
>struts use '('. Another words a mapped property of firstName would
look
>like this in Spring:
>
> value[firstName]
>
>and this in commons validator:
>
> value(firstName)
>
>Commons validator uses '[' for indexed properties. Spring uses '[' =
for
>both indexed and Mapped properties. I think the best place to fix =
this
>problem is on the Spring side in the BeanWrapperImpl. We might as =
well
>be consistent with struts and commons validator in regards to our
>indexed and mapped property sytax. Perhaps we can support both
>syntaxes.=20
>
>Any thoughts?
>
>Karl
> =20
>
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Peter d. H. <pe...@de...> - 2004-04-16 02:37:28
|
Colin Sampaleanu wrote:
> The existing spring approach is also similar to OGNL. In OGNL, '(' is
> used for an actual method call [...] It would make the validation usage
> a bit more similar to commons-validator/struts, but would muddy the
> water for general expression syntax.
Indeed; at some point we might want to support OGNL-like method invocations
and we would have made the expression language a lot more difficult to
parse, implement and also to read. Of course the JSP EL also supports
function invocations, using the foo:bar() syntax. Supporting a property(foo)
syntax might end up being a liability rather than an asset.
- Peter
|
