Re: [Stripes-users] List types and errors

[Mike McNally]

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.


On Mon, Jul 17, 2017 at 10:42 PM Mike McNally  wrote:

> 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.
>
>
> On Mon, Jul 17, 2017 at 10:33 PM Rick Grashel  wrote:
>
>> 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
>>
>> On Jul 17, 2017 10:17 PM, "Mike McNally"  wrote:
>>
>>> 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.
>>>
>>>
>>> On Mon, Jul 17, 2017 at 7:34 PM Rick Grashel  wrote:
>>>
 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






 On Mon, Jul 17, 2017 at 6:44 PM, Mike McNally 
 wrote:

> 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.
>
>
> On Mon, Jul 17, 2017 at 6:42 PM Luis Tiago Rico 
> wrote:
>
>> 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
>>
>> Em 18/07/2017 12:30 da manhã, "Mike McNally" 
>> escreveu:
>>
>>> Ugh.
>>>
>>> I've got a List parameter. Let's say it looks like this:
>>>
>>> private List foo;
>>> public List getFoo() { return fool; }
>>> public void setFoo(List foo) { this.foo = foo; }
>>>
>>> So in my form on the client side I've got several  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?
>>>
>>> On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel 
>>> 

Re: [Stripes-users] List types and errors

[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.


On Mon, Jul 17, 2017 at 10:33 PM Rick Grashel  wrote:

> 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
>
> On Jul 17, 2017 10:17 PM, "Mike McNally"  wrote:
>
>> 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.
>>
>>
>> On Mon, Jul 17, 2017 at 7:34 PM Rick Grashel  wrote:
>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jul 17, 2017 at 6:44 PM, Mike McNally 
>>> wrote:
>>>
 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.


 On Mon, Jul 17, 2017 at 6:42 PM Luis Tiago Rico 
 wrote:

> 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
>
> Em 18/07/2017 12:30 da manhã, "Mike McNally" 
> escreveu:
>
>> Ugh.
>>
>> I've got a List parameter. Let's say it looks like this:
>>
>> private List foo;
>> public List getFoo() { return fool; }
>> public void setFoo(List foo) { this.foo = foo; }
>>
>> So in my form on the client side I've got several  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?
>>
>> On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel 
>> wrote:
>>
>>> 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
>>>
>>> On Mon, Jul 17, 2017 at 6:15 PM, Mike McNally 

Re: [Stripes-users] List types and errors

[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

On Jul 17, 2017 10:17 PM, "Mike McNally"  wrote:

> 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.
>
>
> On Mon, Jul 17, 2017 at 7:34 PM Rick Grashel  wrote:
>
>> 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
>>
>>
>>
>>
>>
>>
>> On Mon, Jul 17, 2017 at 6:44 PM, Mike McNally 
>> wrote:
>>
>>> 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.
>>>
>>>
>>> On Mon, Jul 17, 2017 at 6:42 PM Luis Tiago Rico 
>>> wrote:
>>>
 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

 Em 18/07/2017 12:30 da manhã, "Mike McNally" 
 escreveu:

> Ugh.
>
> I've got a List parameter. Let's say it looks like this:
>
> private List foo;
> public List getFoo() { return fool; }
> public void setFoo(List foo) { this.foo = foo; }
>
> So in my form on the client side I've got several  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?
>
> On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel 
> wrote:
>
>> 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
>>
>> On Mon, Jul 17, 2017 at 6:15 PM, Mike McNally 
>> wrote:
>>
>>> Looping through the errors won't do me any good. The error object
>>> just has the name of the List 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.
>>>
>>>
>>> On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel 
>>> wrote:
>>>
 Hi Mike,

 So are you saying that after Stripes performs 

Re: [Stripes-users] List types and errors

[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.


On Mon, Jul 17, 2017 at 7:34 PM Rick Grashel  wrote:

> 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
>
>
>
>
>
>
> On Mon, Jul 17, 2017 at 6:44 PM, Mike McNally 
> wrote:
>
>> 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.
>>
>>
>> On Mon, Jul 17, 2017 at 6:42 PM Luis Tiago Rico 
>> wrote:
>>
>>> 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
>>>
>>> Em 18/07/2017 12:30 da manhã, "Mike McNally" 
>>> escreveu:
>>>
 Ugh.

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

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

 So in my form on the client side I've got several  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?

 On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel 
 wrote:

> 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
>
> On Mon, Jul 17, 2017 at 6:15 PM, Mike McNally 
> wrote:
>
>> Looping through the errors won't do me any good. The error object
>> just has the name of the List 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.
>>
>>
>> On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel 
>> wrote:
>>
>>> 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 

Re: [Stripes-users] List types and errors

[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
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






On Mon, Jul 17, 2017 at 6:44 PM, Mike McNally  wrote:

> 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.
>
>
> On Mon, Jul 17, 2017 at 6:42 PM Luis Tiago Rico 
> wrote:
>
>> 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
>>
>> Em 18/07/2017 12:30 da manhã, "Mike McNally" 
>> escreveu:
>>
>>> Ugh.
>>>
>>> I've got a List parameter. Let's say it looks like this:
>>>
>>> private List foo;
>>> public List getFoo() { return fool; }
>>> public void setFoo(List foo) { this.foo = foo; }
>>>
>>> So in my form on the client side I've got several  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?
>>>
>>> On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel  wrote:
>>>
 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

 On Mon, Jul 17, 2017 at 6:15 PM, Mike McNally 
 wrote:

> Looping through the errors won't do me any good. The error object just
> has the name of the List 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.
>
>
> On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel 
> wrote:
>
>> 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
>>
>> On Mon, Jul 17, 2017 at 5:50 PM, Mike McNally 
>> wrote:
>>
>>> First, still on Stripes 5.something.
>>>
>>> In actions with List 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 

Re: [Stripes-users] List types and errors

[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.


On Mon, Jul 17, 2017 at 6:42 PM Luis Tiago Rico  wrote:

> 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
>
> Em 18/07/2017 12:30 da manhã, "Mike McNally" 
> escreveu:
>
>> Ugh.
>>
>> I've got a List parameter. Let's say it looks like this:
>>
>> private List foo;
>> public List getFoo() { return fool; }
>> public void setFoo(List foo) { this.foo = foo; }
>>
>> So in my form on the client side I've got several  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?
>>
>> On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel  wrote:
>>
>>> 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
>>>
>>> On Mon, Jul 17, 2017 at 6:15 PM, Mike McNally 
>>> wrote:
>>>
 Looping through the errors won't do me any good. The error object just
 has the name of the List 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.


 On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel 
 wrote:

> 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
>
> On Mon, Jul 17, 2017 at 5:50 PM, Mike McNally 
> wrote:
>
>> First, still on Stripes 5.something.
>>
>> In actions with List 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
>> Stripes-users@lists.sourceforge.net
>> 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
> 

Re: [Stripes-users] List types and errors

[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

Em 18/07/2017 12:30 da manhã, "Mike McNally" 
escreveu:

> Ugh.
>
> I've got a List parameter. Let's say it looks like this:
>
> private List foo;
> public List getFoo() { return fool; }
> public void setFoo(List foo) { this.foo = foo; }
>
> So in my form on the client side I've got several  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?
>
> On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel  wrote:
>
>> 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
>>
>> On Mon, Jul 17, 2017 at 6:15 PM, Mike McNally 
>> wrote:
>>
>>> Looping through the errors won't do me any good. The error object just
>>> has the name of the List 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.
>>>
>>>
>>> On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel  wrote:
>>>
 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

 On Mon, Jul 17, 2017 at 5:50 PM, Mike McNally 
 wrote:

> First, still on Stripes 5.something.
>
> In actions with List 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
> Stripes-users@lists.sourceforge.net
> 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
 Stripes-users@lists.sourceforge.net
 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
>>> Stripes-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>
>>>
>> 

Re: [Stripes-users] List types and errors

[Mike McNally]

Ugh.

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

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

So in my form on the client side I've got several  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?

On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel  wrote:

> 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
>
> On Mon, Jul 17, 2017 at 6:15 PM, Mike McNally 
> wrote:
>
>> Looping through the errors won't do me any good. The error object just
>> has the name of the List 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.
>>
>>
>> On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel  wrote:
>>
>>> 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
>>>
>>> On Mon, Jul 17, 2017 at 5:50 PM, Mike McNally 
>>> wrote:
>>>
 First, still on Stripes 5.something.

 In actions with List 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
 Stripes-users@lists.sourceforge.net
 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
>>> Stripes-users@lists.sourceforge.net
>>> 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
>> Stripes-users@lists.sourceforge.net
>> 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
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

Re: [Stripes-users] List types and errors

[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

On Mon, Jul 17, 2017 at 6:15 PM, Mike McNally  wrote:

> Looping through the errors won't do me any good. The error object just has
> the name of the List 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.
>
>
> On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel  wrote:
>
>> 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
>>
>> On Mon, Jul 17, 2017 at 5:50 PM, Mike McNally 
>> wrote:
>>
>>> First, still on Stripes 5.something.
>>>
>>> In actions with List 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
>>> Stripes-users@lists.sourceforge.net
>>> 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
>> Stripes-users@lists.sourceforge.net
>> 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
> Stripes-users@lists.sourceforge.net
> 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
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] List types and errors

[Mike McNally]

Looping through the errors won't do me any good. The error object just has
the name of the List 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.


On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel  wrote:

> 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
>
> On Mon, Jul 17, 2017 at 5:50 PM, Mike McNally 
> wrote:
>
>> First, still on Stripes 5.something.
>>
>> In actions with List 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
>> Stripes-users@lists.sourceforge.net
>> 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
> Stripes-users@lists.sourceforge.net
> 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
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users