Cheshire,
I agree with you that from a user experience perspective you should
distill/cleanup things as much as possible so that the user has less to sift
through in resolving the errors.
Sounds like you want to attempt your cleanup on error and on validation. It's
been a long time since I worked with Stripes so don't recall how to handle that
anymore.
The other YMMV alternative is to say consider splitting your form such that the
list of images occurs on a separate step that way the other errors can be dealt
with on say a prior step; again I have no idea if in your case this is good or
bad as it depends on how many other form elements you have, how many can have
errors, how is the user experience affected, etc...
--Nikolaos
Sent from my iPhone
On 2013-08-02, at 11:15 AM, Chris Cheshire <cheshira...@gmail.com> wrote:
> The binding error issue dawned on me right after I sent the email.
>
> Dealing with the empty entries isn't a problem in the event handler (just
> check for null first), it's more of an issue on resubmission of the form.
> Part of the validation is to make sure the images being uploaded aren't over
> a specific size. So say 3 urls are entered, and the 2nd one comes back as too
> large. The form gets rendered with the error under that url. The user decides
> to delete the 2nd url and resubmit the form, but there are still validation
> errors elsewhere. Now the form gets rendered with a blank entry in the url
> list.
>
> That's what I am trying to avoid. I'm just trying to clean up the user
> experience.
>
> Fixing one issue causes the other. I want to have my cake eat it too but that
> doesn't look to be possible.
>
> Chris
>
>
>
> On Fri, Aug 2, 2013 at 11:04 AM, Freddy Daoud <xf2...@fastmail.fm> wrote:
>> Hi Chris,
>>
>> I think the reason is, generally, if you submit a form with values and there
>> are validation errors, those values are blocked from being bound on the
>> action bean (validation is about disallowing invalid values, after all).
>> When redisplaying the form and telling the user about the errors, we want to
>> repopulate the form with the submitted values, but those are only available
>> in the request, not from the action bean.
>>
>> Perhaps you could run your list compression only after validation has passed
>> (in the event handler)? In the case of errors, the form would be re-rendered
>> with the values (and error messages) in the same place as the user entered
>> them, but when all URLs are valid, you could then clean up the empty slots
>> before saving.
>>
>> Hope that helps.
>>
>> Cheers,
>> Freddy
>>
>> On Fri, Aug 2, 2013, at 10:48 AM, Chris Cheshire wrote:
>>> I have a form that allows users to enter a series of urls, backed by a list
>>> of strings in the action bean. As a prevalidation method I am removing
>>> empty elements :
>>>
>>> @Before(stages={LifecycleStage.CustomValidation})
>>> public void removeEmptyImages() {
>>> this.log.trace("in removeEmptyImages()");
>>> if (this.images != null) {
>>> // remove any non existant entries
>>> ListIterator<String> iter = this.images.listIterator();
>>> while (iter.hasNext()) {
>>> String img = iter.next();
>>> if (img == null) {
>>> iter.remove();
>>> }
>>> }
>>> }
>>> }
>>>
>>>
>>> So if something was entered in element 0, 1 and 3, the list is compressed
>>> down.
>>>
>>> In a @ValidationMethod, the list has validity checks (making sure the urls
>>> are actually valid etc) performed on it and I don't have to deal with null
>>> values. However when one of those items has an error and the form is
>>> rendered again, the validation errors are in the right place (given that
>>> the list has been compressed), but the form values are not. They are
>>> rendered (or attempting to be) where they originally were, despite using
>>> the BFPS. So once elements are removed I get errors rendered by the wrong
>>> inputs.
>>>
>>> I took a dig into the code thinking there is a bug, and I find in BFPS
>>>
>>> @Override
>>> public Object getValue(InputTagSupport tag) throws StripesJspException {
>>> // If the specific tag is in error, grab the values from the request
>>> if (tag.hasErrors()) {
>>> return super.getValue(tag);
>>> }
>>> else {
>>> // Try getting from the ActionBean. If the bean is present and
>>> the property
>>> // is defined, then the value from the bean takes precedence
>>> even if it's null
>>>
>>>
>>> My question is why is it reverting to request values if the tag has errors?
>>> My first reaction to a solution is to write my own subclass, copying the
>>> code sans the first if block. However, there is probably a good reason for
>>> the BFPS being coded like this, so maybe my solution will bugger something
>>> else.
>>>
>>> What am I missing here?
>>>
>>> Thanks
>>>
>>> Chris
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
