Tabbed form and validation. - admin-on-rest

I'm creating a tabbed form with validation, and there is one thing I don't understand how to do: when I hit the submit button, and there is a validation error in some field, the form is not submitted - but if the field is in an hidden tab (a non focused one), there is no error message displayed either.
Is there am easy way to switch to the tab with errors, or to inhibith focusing on following tabs until all errors in current one had been cleared?
I'm new to all the React, JSX and modern JS development, please do not be too much concise! :)
Thanks!

I reproduced the problem and opened an issue on our repository. I'll let you know how it goes.
In the mean time, one way to mitigate this issue would be to create a custom saga. You'll need some knowledge about redux-saga though.
The idea would be to:
catch failed validations actions from redux-form (SET_SUBMIT_FAILED)
trigger a custom notification with an error message indicating the field and the tab where the error occurred. Unfortunately, you'll have to check the fields names to know for which resource the error occurred.

Related

Lotus Web Form Scroll and Popup issue

I am trying to create a web form in Lotus Notes that is web enabled. So far this has all worked fine, however there are 2 issues.
When Creating a Java Script Alert in the OnLoad Event, it Pops up everytime a user selects a radio button or dropdown option since this reloads the page. Is there any way to make this only for the initial opening of the form?
When a user selects an option, the form reloads and puts that form field on the top which is proving to be very disorrienting for users. Is there a way to have it not scroll on reload?
Thanks in advance!
The best advice would be: use XPages for web development that is "state of the art". If you can't, you have to code a lot of JavaScript to make the form not behave like "havoc".
First of all: the field property "refresh fields on keyword change" is the reason for the jumping / reload.
What does domino do?
All events / formulas that occur when you normally press F9 or use the Option above (that can be field values, input translations, hide whens, etc.) are not "converted" to HTML and javascript but are executed by the server. Therefor each change in a field with the option set submits the form and adds an &Seq=x to the url to keep track of the state. X increments on every reload. Of course this reload causes all events to be triggered again.
For you this means:
Option
disable the option to reload the form after keyword change.
Unfortunately you have to recode every dependency / calculation / hide when with javascript. Using a framework like jquery or dojo this is possible, but a lot of work.
If there IS no dependency then just disable the option...
Option
Live with the "jumping" and let your onload event check for the existance of an URL- parameter called seq... And only if it does not exist, then it is a "real" OnLoad...
Both options are not quite nice and not very easy to code...
That's one reason why IBM started XPages... There all this stuff is already handled by default...

Telerik RadTextbox input behaving like watermark

I've a Telerik RadTextbox in one of my .ascx files in a Sitefinity 5.4 website. When a form containing the RadTextbox is submitted and there is some error thrown by the server, and the user goes back and tries to resubmit the form, there is validation message appearing even if there is input showing from the initial submission. It looks like the input from the first submission is treated as watermark.
Any idea why this is happening?
Is the user going back by using the browser back button? Then the validations will still exist. Try to eliminate the errors by clients side validation first, then server side validations. If the errors still exists, you should clear the validation messages on the load of the control (if it is not a postback of course)

MVC 3 Client Side Validation Catches Some ValidationAttributes but not others?

I'm confused by this behavior:
I have an out-of-the-box MVC3 app. I haven't really done any customization from the what the scaffolding template gives me.
In web.config, clientsidevalidationenabled and unobtrusivevalidation are both true.
I have a class with one field using the Required annotation, one using StringLength and one using RegularExpression. When I'm editing an object, the textboxes for the properties marked with StringLength & Regex report problems instantly in the UI, but the textbox for the Required doesn't.
If I hit SAVE, then "Model.IsValid" is the controller sess the problem with the missing Required and I get the UI error message next to the text box.
If I view the source of the page, I can see that the markup for the required property does have the dataval-req and other related attributes generated by the Unobtrusive validation.
Is this expected behavior? If it is, what's the reason? If it's not, what might I be doing wrong?
Thanks! :)
As long as the page is not posting back to the server, this should be the correct behavior. The required client-validation will fire only if:
You don't enter data and try to post to the server.
You enter data in the text box and then remove it.
Otherwise the user would be inundated with error messages.
I've gotten to the bottom of this behavior, just by banging on the keyboard some more. It's as expected. In the Create view, the behavior is as #Beavis describes. In the edit view, unobtrusive validation prevents the required property from being validated on tabbing BEFORE the first attempt at hitting SAVE. SAVE then does a UI validation (no postback occurs) and shows the error message next to the property. Once I've hit save that first time, that property responds to tabbing. So now if I make it valid, the message disappears on tab. If I erase the contents of the text box, the message reappears on tab.
Thanks for everyone's help.

JQuery Mobile 1.0 - Self-posting pages causing duplicate dialogs or history entries

If you go to http://jsbin.com/ibozun/2, hit "Add Item," and then hit "Save," you will see that a second dialog is opened on top of the first one. The form in the dialog is posting to itself (no action defined) - this is by design. Because the dialog has duplicated itself, now you have to hit "Cancel" 2 times to get it to close.
The use-case for this setup is a MS MVC3 page with unobtrusive JQuery validation on it. The default scripts (in other words, I have no custom validators - the scripts are straight from MS) cause an ajax call to the server, and JQM treats that the same as a self-posting form - so you wind up with a duplicate dialog if validation fails.
A similar thing happens if the second page as a page, rather than a dialog - the form posting to itself results in a second history entry in the browser, so to get back to page 1, you have to hit back 2 times.
I believed this be a bug in JQM, but after submitting a bug on GitHub, I was told that this is the expected behavior. So, assuming this behavior that will not be changing in the framework, how do I prevent this from happening for my instance (preferring NOT to edit the framework JS)? Do I have to write my own ajax calls for validation so that I can prevent JQM from knowing that anything has happened? That seems unfortunate...
One idea I had was to detect that the nextPage and current page are the same on "pageHide", and manipulate the dialog/history myself, but have had no luck.
Thanks in advance!
First, there is no dialog duplication in the example. Second, my response and an explanation as to why solving the history issues with posting back to the same page for users of the library is hard can be found here. This example is particularly thorny because it's also in a dialog which we don't support linking to, so disabling ajax for the form (ie forcing it to reload), which would work if it were embedded in a page, won't serve.
The quick solution here is to switch the dialog to a page and add the data-ajax=false data attribute to the form. Mind you this causes a page flash/reload and requires that the form document be fully formed with a head including javascript,css, etc.

Alert box a good practice or not

I have a web form with more than 10 fields that are submitted to the database. So before submitting the values I am doing JavaScript validation.
Currently I am using JavaScript validation and shows an alert box if an error occurs in data entry.
Is it a good practice to show alert box when JavaScript validation fails or should I use asp.net validation controls to display the error messages?
I'd avoid using an alert box. It's annoying, requires an extra click, and since it's modal - stops the entire browser.Instead, highlight the erroneous fields/values, and print a message at the top, explaining that the highlighted fields need to be corrected before the user can continue.You can use Asp.Net validation, or jQuery form validation - both work equally well.
ASP.NET Validation controls are more recommended, because the alert can be intrusive. They can be set to give messages without posting back, which is ideal.
Just make sure you make it obvious when the form has failed.
from the usability perspective it is much better to use .net validation. Depending on your alert box implementation you may bombard user with many alerts which is very bad.
Also don't rely on client side validation only. Be sure to validate on the server side as well. And this is where .net validation might be handy again.
A good practice is what when your code supports fall back method. For example, if Javascript is disabled then the user should still be able to view the error messages, if any.
More over, they dont look as good as you could style your own divs and display them after some server side validation .. and then use javascript to hide/fade out this error message container div.
I think its a personal/design preference.
Sometimes its just more obvious when there is a javascript alert indicating something needs to be done. Sometimes a small red asterisk gets lost on the page.
In my own opinion, alert boxes are just too annoying to see on websites these days since they're all you see on Windows... But, if you prefer a better looking site, use something else. If you want to make sure the message gets across - then use an alert.

Resources