Consistent Validation & Error Messages about capstone HOT 12 CLOSED

Could use an application wide event handler. I'm building a few of these to handle any database or file system catches.This would only work if we wasn't to use the alert dialog (which I'm not sure is a good idea.)

Here is an example of how to pass data to the listener and use it. That way it would only be one method that would be consisted across the board.

Ti.App.addEventListener('eventName', function(e) {
Ti.API.info( JSON.stringify(e) );
Ti.API.info( JSON.stringify(e.objName) );
});

Ti.App.fireEvent('eventName', {
objName : {x: {p: 'Value'}, y: [1, 2, 3]},
test : 'works'
});

The other option is to use visual prompts. Change the colour of a text box to yellow, place a red x or ! beside the filed in question. The advantage to this is that it is quick to see what is wrong and doesn't have an annoying pop-up. We could accompany this with some error text below the form items that directs the user as to what they need to do.

from capstone.

I can't fully recommend the way transectsModal handles errors right now, because clicking 'Done' doesn't fire the event listener for blur() quick enough to be caught, and invalid values can be stored.

I do however like the visual prompts and instant feedback to the user. Red text directly below the field that is causing an error. A 'revert' or 'undo' button seems useful on this screen in particular.

from capstone.

How are you guys currently validating user input? if statements or should we be using regular expressions?

from capstone.

I'm going by the screen specs for allowed values, and then using something enforces that.

But i think you're asking about an allowed character set for any TextField input. I so far haven't dealt with single and double quotes, and it seems like everything else on the keyboard should be permissible while not interfering with sqlite.

If that's the case, we should decide wether to disable those key presses or escape their characters. I suspect that using the (?, var) sqlite syntax handles single and double quotes automatically, but I have not tested it enough to say for sure.

If we need to restrict more keys for whatever reason (excel spreadsheet, oracle db), we'll have to decide how to handle those as well. It's fairly simple to mask them with a regex and prevent them from registering in the TextField.

When entering a number field, I've restricted the keyboard to only allow number key presses with a regex in transectsModal.js, and Tory said it was good.

from capstone.

Well if you are doing validation on the transect modal then it is kinda pointless for me to be working on it for the addTransect page because the validation will be / should be the same for both. I will leave it for now then as you are working on it and will work on validating the UTM and photo capture data.

That makes the most sense to me? Although I think this is expected to be complete by thursday, thoughts?

PS. I like the way that the event listeners (on change) don't allow the user to input specific characters, seems like that may be the easiest way to prevent them from inserting special chars

from capstone.

I've been using transectsModal.js as a testbed for validation from the user's perspective. It and addTransect.js will end up running the same tests on each field, so for now don't prevent invalid input. I will focus on unit testing very soon. The unit tests can act as the reference for what each field should and shouldn't accept. A field's errors will have to be handled.

from capstone.

I fixed the 'Done' button issues on transectsModal and can now recommend that screen as a template for error handling. We'll discuss some more in person today.

I moved the error checking from TextField.blur() to TextField.change(), which now fires a custom event that validates it's field. Works well for the modal where you are editing values. Some modification will be necessary on 'Add' screens, so red text is not displayed on the first letter typed.

Still working on getting unit testing to fire the change event.

from capstone.

Hey Nick I see that you've added error checking for the Head surveyor using a RegEx. Just wanna make sure that the use of single quotes do not cause problems for the csv export?

Also what do you think about error checking for Other Surveyors?

from capstone.

Good point. The transect modal is updated and masks single and double quotes, making that key press do nothing.

Error checking for other Surveyors is trickier because it's an optional field. It could probably do something like "if not empty, then must be at least 2 words like surveyor"

from capstone.

FWIW: You should probably just encode the CSV instead of filtering the
input. It'll make life easier as you don't have to worry about Mr. O'Brian
and other legit input data. For CSV encoding, use '','', etc.
Escape the legit quotation using a backslash ''. I think Excel accepts
this encoding style but I would double check.

On Wed, May 7, 2014 at 4:29 PM, Nick Gulajec [email protected]:

Good point. The transect modal is updated and masks single and double
quotes, making that key press do nothing.

Error checking for other Surveyors is trickier because it's an optional
field. It could probably do something like "if not empty, then must be at
least 2 words like surveyor"

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-42496035
.

from capstone.

Update: The CSV accepts all characters. A double quote is the only char that needs to be escaped, which now happens.

The current input validation for Surveyor Name is the regex:

/^[a-zA-Z]{1}[a-zA-Z.-',"\s]+\s{1}[a-zA-Z]{1}[a-zA-Z.-',"\s]*$/

...which requires one lowercase or uppercase letter at the beginning of the field, followed by at least one letter (case-insensitive), period, hyphen, apostrophe, comma, double quote, or space, followed by a single space, and then a case-insensitive letter, and then any number (including zero) of the same characters.

This is probably too limiting, un-intuitive, and frustrating to the user, and this issue should stay open until a suitable replacement is found.

from capstone.

Continual feedback over the next three weeks will address all field validation expectations, including this one. Closing.

from capstone.