List types and errors

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

List types and errors

Mike McNally-3
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: List types and errors

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?

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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: List types and errors

Mike McNally-3
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.


On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
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.


On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: List types and errors

Mike McNally-3
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?

On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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.


On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: 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" <[hidden email]> escreveu:
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?

On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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.


On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: List types and errors

Mike McNally-3
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 <[hidden email]> 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" <[hidden email]> escreveu:
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?

On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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.


On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: 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:


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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> escreveu:
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?

On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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.


On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: List types and errors

Mike McNally-3
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 <[hidden email]> 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:


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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> escreveu:
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?

On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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.


On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: 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" <[hidden email]> 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 <[hidden email]> 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:


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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> escreveu:
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?

On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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.


On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: List types and errors

Mike McNally-3
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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:


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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> escreveu:
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?

On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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.


On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: List types and errors

Mike McNally-3
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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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:


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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> escreveu:
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?

On Mon, Jul 17, 2017 at 6:22 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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.


On Mon, Jul 17, 2017 at 6:12 PM Rick Grashel <[hidden email]> 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 <[hidden email]> wrote:
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users