[Stripes-users] List types and errors

Discussion:

Mike McNally

2017-07-17 22:50:26 UTC

First, still on Stripes 5.something.

In actions with List<Foo> arguments, it seems that validation errors are
produced (as far as I can tell) such that it's not possible to determine
which of the parameter values in the list (that is, which of the HTTP
parameters matching the list name) was the one with the problem, or whether
multiple inputs had problems, etc.

Is there something I'm missing, or is that just something that Stripes just
sort of doesn't do?

Rick Grashel

2017-07-17 23:11:52 UTC

Permalink

Hi Mike,

So are you saying that after Stripes performs its validation, you want to
interrogate (from within the ActionBean) to see what validation errors (if
any) occurred?

If so, then you can have a method which is annotated with @After(
LifecycleStage.CustomValidation ). In that method, you can call
getContext().getValidationErrors() and loop through each error (which will
have the field inside of it if it is a field-level error).

Is that what you are wanting?

Thanks.

-- Rick

Post by Mike McNally
First, still on Stripes 5.something.
In actions with List<Foo> arguments, it seems that validation errors are
produced (as far as I can tell) such that it's not possible to determine
which of the parameter values in the list (that is, which of the HTTP
parameters matching the list name) was the one with the problem, or whether
multiple inputs had problems, etc.
Is there something I'm missing, or is that just something that Stripes
just sort of doesn't do?
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

Mike McNally

2017-07-17 23:15:25 UTC

Permalink

Looping through the errors won't do me any good. The error object just has
the name of the List<Foo> parameter, which is shared by all the elements.
Which one has the error? How will I have my UI indicate to the user which
input in the form has a bad value?

I should also note that the value field of the error is wrong; it contains
a value from *one* of the fields, but not the bad one.

Post by Rick Grashel
Hi Mike,
So are you saying that after Stripes performs its validation, you want to
interrogate (from within the ActionBean) to see what validation errors (if
any) occurred?
LifecycleStage.CustomValidation ). In that method, you can call
getContext().getValidationErrors() and loop through each error (which will
have the field inside of it if it is a field-level error).
Is that what you are wanting?
Thanks.
-- Rick

Post by Mike McNally
First, still on Stripes 5.something.
In actions with List<Foo> arguments, it seems that validation errors are
produced (as far as I can tell) such that it's not possible to determine
which of the parameter values in the list (that is, which of the HTTP
parameters matching the list name) was the one with the problem, or whether
multiple inputs had problems, etc.
Is there something I'm missing, or is that just something that Stripes
just sort of doesn't do?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

Rick Grashel

2017-07-17 23:21:13 UTC

Permalink

Hi Mike,

Is there any code you can share? It is really difficult to help here
without some code. But first, I guess we should first start with the
obvious question: "Are you using Stripes form tags?" Secondly, the
validation errors object should not just have the foo parameter. It should
have the nested property within it. So the field name should be "foo.bar".

Thanks.

-- Rick

Post by Mike McNally
Looping through the errors won't do me any good. The error object just has
the name of the List<Foo> parameter, which is shared by all the elements.
Which one has the error? How will I have my UI indicate to the user which
input in the form has a bad value?
I should also note that the value field of the error is wrong; it contains
a value from *one* of the fields, but not the bad one.

Post by Rick Grashel
Hi Mike,
So are you saying that after Stripes performs its validation, you want to
interrogate (from within the ActionBean) to see what validation errors (if
any) occurred?
LifecycleStage.CustomValidation ). In that method, you can call
getContext().getValidationErrors() and loop through each error (which
will have the field inside of it if it is a field-level error).
Is that what you are wanting?
Thanks.
-- Rick

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
_________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

Mike McNally

2017-07-17 23:29:06 UTC

Permalink

Ugh.

I've got a List<Integer> parameter. Let's say it looks like this:

private List<Integer> foo;
public List<Integer> getFoo() { return fool; }
public void setFoo(List<integer> foo) { this.foo = foo; }

So in my form on the client side I've got several <input> tags named "foo"
; that is, their "name" property is "foo".

The answer to whether I'm using Stripes input tags is at best "sort of".
Maybe there's something I don't know about Stripes form tags, but I'm not
sure that would make much difference here.

So the form posts, and the HTTP parameter list includes several "foo=xxx"
parameters. One of them is not a valid integer.

The ScopedLocalizeableError that's created tells me that the error is
related to the form parameter called "foo". It does not indicate in any way
I can find that it's the third "foo" or the seventh "foo" or the tenth; it
just says "this error is about the parameter 'foo'".

Does that clear it up? It seems like a pretty basic issue: does the
validation cycle have a way to indicate exactly which member of a list of
like-named parameter values was the cause of a validation error?

Post by Rick Grashel
Hi Mike,
Is there any code you can share? It is really difficult to help here
without some code. But first, I guess we should first start with the
obvious question: "Are you using Stripes form tags?" Secondly, the
validation errors object should not just have the foo parameter. It should
have the nested property within it. So the field name should be "foo.bar".
Thanks.
-- Rick

Post by Mike McNally
Looping through the errors won't do me any good. The error object just
has the name of the List<Foo> parameter, which is shared by all the
elements. Which one has the error? How will I have my UI indicate to the
user which input in the form has a bad value?
I should also note that the value field of the error is wrong; it
contains a value from *one* of the fields, but not the bad one.

Post by Rick Grashel
Hi Mike,
So are you saying that after Stripes performs its validation, you want
to interrogate (from within the ActionBean) to see what validation errors
(if any) occurred?
LifecycleStage.CustomValidation ). In that method, you can call
getContext().getValidationErrors() and loop through each error (which will
have the field inside of it if it is a field-level error).
Is that what you are wanting?
Thanks.
-- Rick

Post by Mike McNally
First, still on Stripes 5.something.
In actions with List<Foo> arguments, it seems that validation errors
are produced (as far as I can tell) such that it's not possible to
determine which of the parameter values in the list (that is, which of the
HTTP parameters matching the list name) was the one with the problem, or
whether multiple inputs had problems, etc.
Is there something I'm missing, or is that just something that Stripes
just sort of doesn't do?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

Luis Tiago Rico

2017-07-17 23:41:24 UTC

Permalink

Hi. Haven't using stripes for a while now. But I would say on your form to
loop your inputs and name them foo[i]. Also use annotations in action beans
to validate as said before.

Hope it helps writing this on my mobile phone

Post by Mike McNally
Ugh.
private List<Integer> foo;
public List<Integer> getFoo() { return fool; }
public void setFoo(List<integer> foo) { this.foo = foo; }
So in my form on the client side I've got several <input> tags named "foo"
; that is, their "name" property is "foo".
The answer to whether I'm using Stripes input tags is at best "sort of".
Maybe there's something I don't know about Stripes form tags, but I'm not
sure that would make much difference here.
So the form posts, and the HTTP parameter list includes several "foo=xxx"
parameters. One of them is not a valid integer.
The ScopedLocalizeableError that's created tells me that the error is
related to the form parameter called "foo". It does not indicate in any way
I can find that it's the third "foo" or the seventh "foo" or the tenth; it
just says "this error is about the parameter 'foo'".
Does that clear it up? It seems like a pretty basic issue: does the
validation cycle have a way to indicate exactly which member of a list of
like-named parameter values was the cause of a validation error?

Post by Mike McNally
Looping through the errors won't do me any good. The error object just
has the name of the List<Foo> parameter, which is shared by all the
elements. Which one has the error? How will I have my UI indicate to the
user which input in the form has a bad value?
I should also note that the value field of the error is wrong; it
contains a value from *one* of the fields, but not the bad one.

Post by Rick Grashel
Hi Mike,
So are you saying that after Stripes performs its validation, you want
to interrogate (from within the ActionBean) to see what validation errors
(if any) occurred?
LifecycleStage.CustomValidation ). In that method, you can call
getContext().getValidationErrors() and loop through each error (which
will have the field inside of it if it is a field-level error).
Is that what you are wanting?
Thanks.
-- Rick

Post by Mike McNally
First, still on Stripes 5.something.
In actions with List<Foo> arguments, it seems that validation errors
are produced (as far as I can tell) such that it's not possible to
determine which of the parameter values in the list (that is, which of the
HTTP parameters matching the list name) was the one with the problem, or
whether multiple inputs had problems, etc.
Is there something I'm missing, or is that just something that Stripes
just sort of doesn't do?
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
_________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
_________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

Mike McNally

2017-07-17 23:44:40 UTC

Permalink

Thank you. No, that does not help; the parameters are already named with
[n] suffixes. The error object seems to be instantiated without that
suffix. The relevant action objects are already annotated appropriately,
though in this case it's a simple matter of basic numeric syntax so no
annotation is relevant.

Post by Luis Tiago Rico
Hi. Haven't using stripes for a while now. But I would say on your form to
loop your inputs and name them foo[i]. Also use annotations in action beans
to validate as said before.
Hope it helps writing this on my mobile phone

Post by Mike McNally
Ugh.
private List<Integer> foo;
public List<Integer> getFoo() { return fool; }
public void setFoo(List<integer> foo) { this.foo = foo; }
So in my form on the client side I've got several <input> tags named
"foo" ; that is, their "name" property is "foo".
The answer to whether I'm using Stripes input tags is at best "sort of".
Maybe there's something I don't know about Stripes form tags, but I'm not
sure that would make much difference here.
So the form posts, and the HTTP parameter list includes several "foo=xxx"
parameters. One of them is not a valid integer.
The ScopedLocalizeableError that's created tells me that the error is
related to the form parameter called "foo". It does not indicate in any way
I can find that it's the third "foo" or the seventh "foo" or the tenth; it
just says "this error is about the parameter 'foo'".
Does that clear it up? It seems like a pretty basic issue: does the
validation cycle have a way to indicate exactly which member of a list of
like-named parameter values was the cause of a validation error?

Post by Mike McNally
Looping through the errors won't do me any good. The error object just
has the name of the List<Foo> parameter, which is shared by all the
elements. Which one has the error? How will I have my UI indicate to the
user which input in the form has a bad value?
I should also note that the value field of the error is wrong; it
contains a value from *one* of the fields, but not the bad one.

Post by Rick Grashel
Hi Mike,
So are you saying that after Stripes performs its validation, you want
to interrogate (from within the ActionBean) to see what validation errors
(if any) occurred?
LifecycleStage.CustomValidation ). In that method, you can call
getContext().getValidationErrors() and loop through each error (which will
have the field inside of it if it is a field-level error).
Is that what you are wanting?
Thanks.
-- Rick

Post by Mike McNally
First, still on Stripes 5.something.
In actions with List<Foo> arguments, it seems that validation errors
are produced (as far as I can tell) such that it's not possible to
determine which of the parameter values in the list (that is, which of the
HTTP parameters matching the list name) was the one with the problem, or
whether multiple inputs had problems, etc.
Is there something I'm missing, or is that just something that
Stripes just sort of doesn't do?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

Rick Grashel

2017-07-18 00:33:31 UTC

Permalink

Hi Mike,

I don't know the exact version of Stripes that you are on -- and if there
is maybe a bug with it in your version -- but Luis is correct. This should
work with IndexedProperties:

https://stripesframework.atlassian.net/wiki/display/STRIPES/Indexed+Properties

I am certain that indexed properties do work for the purposes of
highlighting the exact field which has an issue. So you should have inputs
with the names like foo[0], foo[1], foo[2], foo[3], et cetera. I am also
certain that the field names should contain "foo[3]" for the parameter if
you are naming the inputs correctly. If you are only naming your inputs
with "foo", that that will not work because that is not how indexed
properties should be named if you want to obtain and use index information.

Thanks.

-- Rick

Post by Mike McNally
Thank you. No, that does not help; the parameters are already named with
[n] suffixes. The error object seems to be instantiated without that
suffix. The relevant action objects are already annotated appropriately,
though in this case it's a simple matter of basic numeric syntax so no
annotation is relevant.

Post by Luis Tiago Rico
Hi. Haven't using stripes for a while now. But I would say on your form
to loop your inputs and name them foo[i]. Also use annotations in action
beans to validate as said before.
Hope it helps writing this on my mobile phone

Post by Mike McNally
Ugh.
private List<Integer> foo;
public List<Integer> getFoo() { return fool; }
public void setFoo(List<integer> foo) { this.foo = foo; }
So in my form on the client side I've got several <input> tags named
"foo" ; that is, their "name" property is "foo".
The answer to whether I'm using Stripes input tags is at best "sort
of". Maybe there's something I don't know about Stripes form tags, but I'm
not sure that would make much difference here.
So the form posts, and the HTTP parameter list includes several
"foo=xxx" parameters. One of them is not a valid integer.
The ScopedLocalizeableError that's created tells me that the error is
related to the form parameter called "foo". It does not indicate in any way
I can find that it's the third "foo" or the seventh "foo" or the tenth; it
just says "this error is about the parameter 'foo'".
Does that clear it up? It seems like a pretty basic issue: does the
validation cycle have a way to indicate exactly which member of a list of
like-named parameter values was the cause of a validation error?

Post by Mike McNally
Looping through the errors won't do me any good. The error object just
has the name of the List<Foo> parameter, which is shared by all the
elements. Which one has the error? How will I have my UI indicate to the
user which input in the form has a bad value?
I should also note that the value field of the error is wrong; it
contains a value from *one* of the fields, but not the bad one.

Post by Rick Grashel
Hi Mike,
So are you saying that after Stripes performs its validation, you
want to interrogate (from within the ActionBean) to see what validation
errors (if any) occurred?
LifecycleStage.CustomValidation ). In that method, you can call
getContext().getValidationErrors() and loop through each error
(which will have the field inside of it if it is a field-level error).
Is that what you are wanting?
Thanks.
-- Rick

Post by Mike McNally
First, still on Stripes 5.something.
In actions with List<Foo> arguments, it seems that validation errors
are produced (as far as I can tell) such that it's not possible to
determine which of the parameter values in the list (that is, which of the
HTTP parameters matching the list name) was the one with the problem, or
whether multiple inputs had problems, etc.
Is there something I'm missing, or is that just something that
Stripes just sort of doesn't do?
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
_________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
_________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------

------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
_________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

Mike McNally

2017-07-18 03:15:57 UTC

Permalink

Rick, my form fields do indeed have bracket-encased indexes in the field
names, and I can verify that by the simple expedient of looking at the HTTP
content from either the browser or the server log. The indexes apparently
makes no difference.

I'm on Stripes 5.4.

Post by Rick Grashel
Hi Mike,
I don't know the exact version of Stripes that you are on -- and if there
is maybe a bug with it in your version -- but Luis is correct. This should
https://stripesframework.atlassian.net/wiki/display/STRIPES/Indexed+Properties
I am certain that indexed properties do work for the purposes of
highlighting the exact field which has an issue. So you should have inputs
with the names like foo[0], foo[1], foo[2], foo[3], et cetera. I am also
certain that the field names should contain "foo[3]" for the parameter if
you are naming the inputs correctly. If you are only naming your inputs
with "foo", that that will not work because that is not how indexed
properties should be named if you want to obtain and use index information.
Thanks.
-- Rick

Post by Luis Tiago Rico
Hi. Haven't using stripes for a while now. But I would say on your form
to loop your inputs and name them foo[i]. Also use annotations in action
beans to validate as said before.
Hope it helps writing this on my mobile phone

Post by Mike McNally
Ugh.
private List<Integer> foo;
public List<Integer> getFoo() { return fool; }
public void setFoo(List<integer> foo) { this.foo = foo; }
So in my form on the client side I've got several <input> tags named
"foo" ; that is, their "name" property is "foo".
The answer to whether I'm using Stripes input tags is at best "sort
of". Maybe there's something I don't know about Stripes form tags, but I'm
not sure that would make much difference here.
So the form posts, and the HTTP parameter list includes several
"foo=xxx" parameters. One of them is not a valid integer.
The ScopedLocalizeableError that's created tells me that the error is
related to the form parameter called "foo". It does not indicate in any way
I can find that it's the third "foo" or the seventh "foo" or the tenth; it
just says "this error is about the parameter 'foo'".
Does that clear it up? It seems like a pretty basic issue: does the
validation cycle have a way to indicate exactly which member of a list of
like-named parameter values was the cause of a validation error?

Post by Mike McNally
Looping through the errors won't do me any good. The error object
just has the name of the List<Foo> parameter, which is shared by all the
elements. Which one has the error? How will I have my UI indicate to the
user which input in the form has a bad value?
I should also note that the value field of the error is wrong; it
contains a value from *one* of the fields, but not the bad one.

Post by Rick Grashel
Hi Mike,
So are you saying that after Stripes performs its validation, you
want to interrogate (from within the ActionBean) to see what validation
errors (if any) occurred?
LifecycleStage.CustomValidation ). In that method, you can call
getContext().getValidationErrors() and loop through each error (which will
have the field inside of it if it is a field-level error).
Is that what you are wanting?
Thanks.
-- Rick

Post by Mike McNally
First, still on Stripes 5.something.
In actions with List<Foo> arguments, it seems that validation
errors are produced (as far as I can tell) such that it's not possible to
determine which of the parameter values in the list (that is, which of the
HTTP parameters matching the list name) was the one with the problem, or
whether multiple inputs had problems, etc.
Is there something I'm missing, or is that just something that
Stripes just sort of doesn't do?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

Rick Grashel

2017-07-18 03:32:59 UTC

Permalink

Hi Mike,

It might be a bug in 1.5.4 then. You should try it with a later release or
the most current release to see if it behaves the same way.

I have a few Stripes-based applications in production and use indexed
properties heavily. I haven't seen this issue.

-- Rick

Post by Mike McNally
Rick, my form fields do indeed have bracket-encased indexes in the field
names, and I can verify that by the simple expedient of looking at the HTTP
content from either the browser or the server log. The indexes apparently
makes no difference.
I'm on Stripes 5.4.

Post by Rick Grashel
Hi Mike,
I don't know the exact version of Stripes that you are on -- and if there
is maybe a bug with it in your version -- but Luis is correct. This should
https://stripesframework.atlassian.net/wiki/display/
STRIPES/Indexed+Properties
I am certain that indexed properties do work for the purposes of
highlighting the exact field which has an issue. So you should have inputs
with the names like foo[0], foo[1], foo[2], foo[3], et cetera. I am also
certain that the field names should contain "foo[3]" for the parameter if
you are naming the inputs correctly. If you are only naming your inputs
with "foo", that that will not work because that is not how indexed
properties should be named if you want to obtain and use index information.
Thanks.
-- Rick

Post by Luis Tiago Rico
Hi. Haven't using stripes for a while now. But I would say on your form
to loop your inputs and name them foo[i]. Also use annotations in action
beans to validate as said before.
Hope it helps writing this on my mobile phone

Post by Mike McNally
Ugh.
private List<Integer> foo;
public List<Integer> getFoo() { return fool; }
public void setFoo(List<integer> foo) { this.foo = foo; }
So in my form on the client side I've got several <input> tags named
"foo" ; that is, their "name" property is "foo".
The answer to whether I'm using Stripes input tags is at best "sort
of". Maybe there's something I don't know about Stripes form tags, but I'm
not sure that would make much difference here.
So the form posts, and the HTTP parameter list includes several
"foo=xxx" parameters. One of them is not a valid integer.
The ScopedLocalizeableError that's created tells me that the error is
related to the form parameter called "foo". It does not indicate in any way
I can find that it's the third "foo" or the seventh "foo" or the tenth; it
just says "this error is about the parameter 'foo'".
Does that clear it up? It seems like a pretty basic issue: does the
validation cycle have a way to indicate exactly which member of a list of
like-named parameter values was the cause of a validation error?

Post by Mike McNally
Looping through the errors won't do me any good. The error object
just has the name of the List<Foo> parameter, which is shared by all the
elements. Which one has the error? How will I have my UI indicate to the
user which input in the form has a bad value?
I should also note that the value field of the error is wrong; it
contains a value from *one* of the fields, but not the bad one.

Post by Rick Grashel
Hi Mike,
So are you saying that after Stripes performs its validation, you
want to interrogate (from within the ActionBean) to see what validation
errors (if any) occurred?
LifecycleStage.CustomValidation ). In that method, you can call
getContext().getValidationErrors() and loop through each error
(which will have the field inside of it if it is a field-level error).
Is that what you are wanting?
Thanks.
-- Rick

Post by Mike McNally
First, still on Stripes 5.something.
In actions with List<Foo> arguments, it seems that validation
errors are produced (as far as I can tell) such that it's not possible to
determine which of the parameter values in the list (that is, which of the
HTTP parameters matching the list name) was the one with the problem, or
whether multiple inputs had problems, etc.
Is there something I'm missing, or is that just something that
Stripes just sort of doesn't do?
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
_________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
_________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
_________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

Mike McNally

2017-07-18 03:42:14 UTC

Permalink

Actually my apologies; the input elements don't have the bracketed id's.
They do at some point in my template code but that's stripped off at some
point. However, Stripes is not supposed to require those, as I understand
things. It is certainly able to bind the parameters into the server-side
objects properly without the indexes explicitly being part of the parameter
names.

I'll see what I can do to make the indexes stick around.

Post by Rick Grashel
Hi Mike,
It might be a bug in 1.5.4 then. You should try it with a later release or
the most current release to see if it behaves the same way.
I have a few Stripes-based applications in production and use indexed
properties heavily. I haven't seen this issue.
-- Rick

Post by Rick Grashel
Hi Mike,
I don't know the exact version of Stripes that you are on -- and if
there is maybe a bug with it in your version -- but Luis is correct. This
https://stripesframework.atlassian.net/wiki/display/STRIPES/Indexed+Properties
I am certain that indexed properties do work for the purposes of
highlighting the exact field which has an issue. So you should have inputs
with the names like foo[0], foo[1], foo[2], foo[3], et cetera. I am also
certain that the field names should contain "foo[3]" for the parameter if
you are naming the inputs correctly. If you are only naming your inputs
with "foo", that that will not work because that is not how indexed
properties should be named if you want to obtain and use index information.
Thanks.
-- Rick

Post by Mike McNally
Thank you. No, that does not help; the parameters are already named
with [n] suffixes. The error object seems to be instantiated without that
suffix. The relevant action objects are already annotated appropriately,
though in this case it's a simple matter of basic numeric syntax so no
annotation is relevant.

Post by Luis Tiago Rico
Hi. Haven't using stripes for a while now. But I would say on your
form to loop your inputs and name them foo[i]. Also use annotations in
action beans to validate as said before.
Hope it helps writing this on my mobile phone

Post by Mike McNally
Ugh.
private List<Integer> foo;
public List<Integer> getFoo() { return fool; }
public void setFoo(List<integer> foo) { this.foo = foo; }
So in my form on the client side I've got several <input> tags named
"foo" ; that is, their "name" property is "foo".
The answer to whether I'm using Stripes input tags is at best "sort
of". Maybe there's something I don't know about Stripes form tags, but I'm
not sure that would make much difference here.
So the form posts, and the HTTP parameter list includes several
"foo=xxx" parameters. One of them is not a valid integer.
The ScopedLocalizeableError that's created tells me that the error is
related to the form parameter called "foo". It does not indicate in any way
I can find that it's the third "foo" or the seventh "foo" or the tenth; it
just says "this error is about the parameter 'foo'".
Does that clear it up? It seems like a pretty basic issue: does the
validation cycle have a way to indicate exactly which member of a list of
like-named parameter values was the cause of a validation error?

Post by Rick Grashel
Hi Mike,
Is there any code you can share? It is really difficult to help
here without some code. But first, I guess we should first start with the
obvious question: "Are you using Stripes form tags?" Secondly, the
validation errors object should not just have the foo parameter. It should
have the nested property within it. So the field name should be "foo.bar".
Thanks.
-- Rick

Post by Mike McNally
Looping through the errors won't do me any good. The error object
just has the name of the List<Foo> parameter, which is shared by all the
elements. Which one has the error? How will I have my UI indicate to the
user which input in the form has a bad value?
I should also note that the value field of the error is wrong; it
contains a value from *one* of the fields, but not the bad one.

Post by Rick Grashel
Hi Mike,
So are you saying that after Stripes performs its validation, you
want to interrogate (from within the ActionBean) to see what validation
errors (if any) occurred?
LifecycleStage.CustomValidation ). In that method, you can call
getContext().getValidationErrors() and loop through each error (which will
have the field inside of it if it is a field-level error).
Is that what you are wanting?
Thanks.
-- Rick
On Mon, Jul 17, 2017 at 5:50 PM, Mike McNally <

Post by Mike McNally
First, still on Stripes 5.something.
In actions with List<Foo> arguments, it seems that validation
errors are produced (as far as I can tell) such that it's not possible to
determine which of the parameter values in the list (that is, which of the
HTTP parameters matching the list name) was the one with the problem, or
whether multiple inputs had problems, etc.
Is there something I'm missing, or is that just something that
Stripes just sort of doesn't do?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users

Mike McNally

2017-07-18 03:49:04 UTC

Permalink

Yea that does it; apparently the more-or-less "raw" name from the HTTP
parameters is what decides how the ValidationError object is initialized.
Using the un-indexed names works fine when the parameter values are OK
(they get added to the list(s) as you'd expect) but the validation
mechanism seems to rely on the passed-in name strings.

Thanks very much for your insight and suggestions.

Post by Mike McNally
Actually my apologies; the input elements don't have the bracketed id's.
They do at some point in my template code but that's stripped off at some
point. However, Stripes is not supposed to require those, as I understand
things. It is certainly able to bind the parameters into the server-side
objects properly without the indexes explicitly being part of the parameter
names.
I'll see what I can do to make the indexes stick around.

Post by Rick Grashel
Hi Mike,
It might be a bug in 1.5.4 then. You should try it with a later release
or the most current release to see if it behaves the same way.
I have a few Stripes-based applications in production and use indexed
properties heavily. I haven't seen this issue.
-- Rick

Post by Mike McNally
Thank you. No, that does not help; the parameters are already named
with [n] suffixes. The error object seems to be instantiated without that
suffix. The relevant action objects are already annotated appropriately,
though in this case it's a simple matter of basic numeric syntax so no
annotation is relevant.

Post by Luis Tiago Rico
Hi. Haven't using stripes for a while now. But I would say on your
form to loop your inputs and name them foo[i]. Also use annotations in
action beans to validate as said before.
Hope it helps writing this on my mobile phone

Post by Mike McNally
Ugh.
private List<Integer> foo;
public List<Integer> getFoo() { return fool; }
public void setFoo(List<integer> foo) { this.foo = foo; }
So in my form on the client side I've got several <input> tags named
"foo" ; that is, their "name" property is "foo".
The answer to whether I'm using Stripes input tags is at best "sort
of". Maybe there's something I don't know about Stripes form tags, but I'm
not sure that would make much difference here.
So the form posts, and the HTTP parameter list includes several
"foo=xxx" parameters. One of them is not a valid integer.
The ScopedLocalizeableError that's created tells me that the error
is related to the form parameter called "foo". It does not indicate in any
way I can find that it's the third "foo" or the seventh "foo" or the tenth;
it just says "this error is about the parameter 'foo'".
Does that clear it up? It seems like a pretty basic issue: does the
validation cycle have a way to indicate exactly which member of a list of
like-named parameter values was the cause of a validation error?

Post by Rick Grashel
Hi Mike,
Is there any code you can share? It is really difficult to help
here without some code. But first, I guess we should first start with the
obvious question: "Are you using Stripes form tags?" Secondly, the
validation errors object should not just have the foo parameter. It should
have the nested property within it. So the field name should be "foo.bar".
Thanks.
-- Rick

Post by Mike McNally
Looping through the errors won't do me any good. The error object
just has the name of the List<Foo> parameter, which is shared by all the
elements. Which one has the error? How will I have my UI indicate to the
user which input in the form has a bad value?
I should also note that the value field of the error is wrong; it
contains a value from *one* of the fields, but not the bad one.

Post by Rick Grashel
Hi Mike,
So are you saying that after Stripes performs its validation, you
want to interrogate (from within the ActionBean) to see what validation
errors (if any) occurred?
LifecycleStage.CustomValidation ). In that method, you can call
getContext().getValidationErrors() and loop through each error (which will
have the field inside of it if it is a field-level error).
Is that what you are wanting?
Thanks.
-- Rick
On Mon, Jul 17, 2017 at 5:50 PM, Mike McNally <

Post by Mike McNally
First, still on Stripes 5.something.
In actions with List<Foo> arguments, it seems that validation
errors are produced (as far as I can tell) such that it's not possible to
determine which of the parameter values in the list (that is, which of the
HTTP parameters matching the list name) was the one with the problem, or
whether multiple inputs had problems, etc.
Is there something I'm missing, or is that just something that
Stripes just sort of doesn't do?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Stripes-users mailing list
https://lists.sourceforge.net/lists/listinfo/stripes-users