By "cleaned" I mean formatting inputs such as "a1b2c3" into "A1B 2C3" or "5551234567" into "(555) 123-4567". I figure we have few options:
As the user is typing. For instance, when a user is typing a postal code, all letters are instantly capitalized, or after the user types 3 digits of a phone number, it puts brackets around them.
When the field loses focus.
Never. Formatting happens on the server-side only, just before it is inserted into the DB. The user never gets to see how it was formatted unless it is displayed on the site somewhere.
(3b) If there were form errors, or on the confirmation page. If there are form errors and the form needs to be re-displayed, the formatting on the valid inputs will appear, or if you have a confirmation page (are these inputs correct?) they will show there.
Never ever. Data should be dumped into the database as-is and only formatted in the template/view just before it is displayed back to the user.
What do you think? I think I like (2). Reminds me of how code-formatting works in Visual Studio (happens when you close a brace or type a semi-colon).
I like to either filter the field just after it loses focus (when it is critical that the field be formatted correctly before they move on to the next field - which is rarely), or I filter the field content as soon as the user hits the "SUBMIT" button (or whatever you want to call it) to send the data to the server.
This has a few advantages for me:
The user's input is not interrupted with annoying "auto-corrections" - being auto-corrected can sometimes feel like demonic possession if it is not done well.
The user really neither cares, nor needs to know that you do not want the (,), or -, in your phone number field... so take it out quietly for them. No notes, or instructions needed.
Also, I ALWAYS filter the field values anyway to protect against any kind of code-injection attacks (which are alarmingly easy to pull off if you know what you are doing). I have read about entire databases being compromised because the author did not remove potential SQL markup from submitted data.... it makes me shudder.
It also allows me to check for ALL input errors (if any), or non-filled-out required fields and report a single set of issues to the user at a single time... I have been to sites that give you so many messages while filling out a form it feels a bit like having a nagging relative over your shoulder.
I'd go with either (1) or (2), depending on the kind of input. (1) is probably most user-friendly if done right, but it will be more complex to implement neatly (e.g., what happens if I delete a digit from a hyphenated phone number - or a hyphen?). Go with (1) if you can afford it, otherwise (2).
I follow the same method I use for validation. Once on the client side, once on the server side. Whether it happens on loose focus or as they type it doesn't really matter.
As the user is typing. For instance, when a user is typing a postal code, all letters are instantly capitalized, or after the user types 3 digits of a phone number, it puts brackets around them.
This type of input is excellent for things such as entering serial codes or CD keys for software or games. I notice a lot of people get confused whether or not the code is case sensitive or if they should be inputting the dashes as well.
If you have an iPhone you'll notice when entering a phone number it is also auto formatted with brackets and spaces as you enter it. But this often turns out to be confusing as a partially typed number is not always 'grouped' correctly.
Answer: It all depends on context.
Related
For more readability I would like to add spaces around the arguments in a service's check command. Running a nagios check outputs an error as it seems to want everything on one likeso:
One line check_command definition
However I would like to spcify the check command likeso:
separate lines check command
It’s not possible. Nagios parses configuration attributes by the logic “attribute value \n” so that’s how it has to look.
Other options include breaking it up into multiple check commands, thereby reducing the amount of macros. It’s hard to say since you don’t share the actual text.
On that note, do not share text in pictures. Ever. For any reason. Copy the text and format it as monospaced. If it contains sensitive information, redact it from the text, don’t draw on a picture. Sharing text as pictures is a great way to become very unpopular with colleagues, support personell, and anyone else you come in contact with who has to be able to access the actual text itself, or just want to be able to read it (they may use a screen reader).
How do I make an input field mandatory in VSCode ShowInputBox?
I do not want the user to be able to escape out. I know I can trap the response to be undefined which tells me that the user did in fact escape but I then want to reissue the ShowInputbox. That becomes really messy. It would be cleaner to remain in the ShowInputBox and not proceed till data is present. "validateInput" is not an option as it doesn't get called when escape is pressed.
Is there any means of either suppressing the Escape key or trapping it such that the user has to enter some data into the field.
Seems a simple request but I cannot find any means of accomplishing this.
Before I get reamed for this, I know there are some posts detailing how to clear ALL the output from a cell, but I'm interested in only clearing part of it.
Let me provide some background. I am creating a word-guessing game like LINGO where the user is prompted to guess a five-letter word, then using CSS to provide some visual feedback as to which letters are in the correct position, and which letters are in the word but in the wrong position. The way my program is structured, it displays the feedback after each guess and then prompts the user again and displays the guess. So something like this:
Guess a word: word
FEEDBACK
guess again: word
FEEDBACK
...
You get the picture. My goal is to come as close to duplicating LINGO as possible, which would mean removing the user input from the screen after it has been submitted and having it show a sequence of feedback. This to me means one of three things:
1) Find a way to clear part of the output
2) Find a way to prompt the user for text input without displaying it on the screen
3) Cache the user input, delete the all the output after each iteration, and display the cached guesses.
I've researched 1 and 2 and haven't been able to find anything. 3 would be a PITA so before I went to the trouble I thought I would ask.
1 think is either not possible or very difficult - it's hard in regular python, never mind Jupyter. In regular python, you'd probably use something like curses but I tried it in Jupyter and it affects the console Jupyter is running from - not the stdout in the notebook.
If you really wanted 2, you could probably write your own version of input that uses carriage return \r after stripping the trailing newline via writing a function that loops listening for keystrokes and submitting once a newline is pressed. The carriage return should mean that the next line overwrites the previous line.
3 Caching the input shouldn't be too difficult though I presume? Just store them in an array or something then you can display them back to the user after using IPython.display.clear_output.
My teacher says our homework program must handle "an arbitrary number of input lines". It seems pretty arbitrary to only accept one line, but is it arbitrary enough? My roommate said seven is more a arbitrary number than one, and maybe he's right. But I just have no idea how to measure the arbitrariness of a number and Google doesn't seem to help.
UPDATE:
It sounds like maybe the best thing to do is accepty any given number of input lines, and hope the prof can see that that makes a lot more sense than insisting that the user just give you one specific arbitrary number of input lines. Especially since we weren't instructed to notify the user about what the arbitrary number is. You can't just make the user guess, that's crazy.
"Arbitrary" doesn't mean you get to pick a random number to accept. It means that it should handle an input with any number of lines.
So if someone decides to give your program an input with 0 lines, 1 line, 2 lines... n lines, then it should still do the right thing (and not crash).
Arbitrary means it could be ANY number. 0, 1, 7, 100124453225.
I would probably test for 0 and display some sort of error in that case since it's supposed to have SOME text. Other than that so long as there are more lines your program should keep doing whatever it's designed to do.
Typically when teachers indicate that a program should accept arbitrary amounts of input they are indicating to you that you should consider corner cases which you may not have thought about, one of the most common being no input at all which can often cause errors in programs if the programmer hasn't considered this case.
The point of the word is to emphasize that your program should be able to handle different inputs instead of simply crashing unless input comes in a certain quantity or is formatted in a specific way.
I've built a number of work-specific helper functions that could be useful for other members of my team&mdash. But I've written them all in Emacs' Elisp, and getting them to convert from Notepad++ is NOT going to happen.
So, I'm thinking convert the functions to Perl. No problem.
Except I use ido-completion all the time to limit responses:
(setq client (ido-completing-read "Select a Client: " '("IniTrade" "HedgeCorp" "GlobalTech" "OCP") nil t))
EDIT: ido-completing-read is similar to completing-read, except that all the options are visible, and can be selected via cycling [arrow-keys, usually] or typing-completion. In the example above, the prompt would look like
Select a Client: {IniTrade | HedgeCorp | GlobalTech | OCP}
selections can be made on the left-most item by hitting RET, or by partial typing (in this case, the first letters are all unique, so that's all that would be needed, and the matching item would become the left-most).
nil in the example is an unused param, but "t" requires an exact match -- eg, the user must make one of the selections. The function returns a string, such as "IniTrade".
My "helper functions" are for internal needs -- opening a particular error log, restoring a batch to the server, etc. For these operations, the user needs to specify test or production environment, client, stage, etc. In almost all cases, these are string selections that are used for building another shell command. If a numeric item is returned, that could in turn be re-translated to a string -- but since the selections are usually the required string, it would be nice if that step could be skipped. [end EDIT]
Is there a Perl equivalent? I've looked at Term::Prompt which offers up a numbered-menu... closest I've found. That's not as pretty as ido-completion, and I'd still have to convert a numeric-result backwards to a string (not a major issue; just annoying).
While composing this, I noticed I used the term 'menu', so did some more searching and came up with Term::Menus. I haven't tried this one yet.
Term::ReadLine may do what you're looking for, though it's probably more like 'completing-read' than 'ido-completing-read'.