Validating input with jQuery autocomplete plugin - json

I'm using the standard autocomplete plugin here.
I have two text boxes on my form, item name and item id. The idea is that I want the user to search for the item by name, but on form submit I actually need the item id.
I am returning json from an ASP.NET MVC action which is used in the autocomplete.
The user starts typing an item name, the autocomplete list appears and is formatted to show the item name from the json object. The user can then click on a name from the list and the item id will be populated in the other textbox (which will actually be a hidden field once everything is working). I can then check that there is a value in this second textbox before submitting the form.
In the above scenario everything works great. But there are two huge bugs in what I've got so far:
1) The user has to actually click on the item in the list for the result function to fire. So if there is an item apples, and the user simply types apples directly into the textbox, the item id doesn't get populated.
2) The user could select apples from the list, which populates the item id. The user then changes his mind and goes back to the text box and types oranges. Again, if he doesn't actually click on the item in the list, the item id doesn't change and now when the form is submitted the wrong item id is submitted. Same thing if the user types something which isn't a valid selection, for example he changes the textbox to applesblahblahblah, the item id of apples is still going to be submitted even though a valid item choice wasn't made.
I've seen examples which suggest this can be solved by firing the search event, but I've tried that and it doesn't really seem to do much.
Does anyone know how to solve this problem?
My code so far is below, it's all pretty standard at the moment...
$('#ItemSearch').autocomplete("MyAction/FindItems", {
dataType: 'json',
parse: function(data) {
var parsed = [];
for (var i = 0; i < data.length; i++) {
parsed[parsed.length] = {
data: data[i],
value: data[i].Value,
result: data[i].Key
};
}
return parsed;
},
formatItem: function(row) {
return row.Value;
}
}).result(function(event, data, formatted) {
$(this).val(data.Value);
$('#ItemId').val(data.Key);
}).blur(function() {
// this is where I was trying to force an update of the item id textbox,
// but it doesn't work.
$(this).search();
});
I'd be greatful for any pointers. Thanks
Edit: If there is a better autocomplete which handles json and forced validation I'd be happy to hear suggestions as it might be easier than trying to get this one to work.

A better autocomplete may be the jQuery UI autocomplete, which does require the jQuery UI (pretty big library), but is more flexible. It has plenty of events that you can use to force validation.

Related

How do I build a simple HTML form to construct a link from two form fields?

At work, one of the systems I use outputs voyage schedules. The URL for each voyage is constructed as the form address followed by ?voyageCode= followed by the voyage number, which is a two-letter route prefix and a three-digit voyage number.
Rather than use the standard form, which has a whole bunch of fields I never need to use, I want to build a simple page where I can just select the route and enter a voyage number.
In practical terms, I'm trying to build a form with the following:
A drop-down menu or set of radio buttons to select the two-letter route code;
A text field to enter the three-digit route code;
A button or link to combine those inputs into a link in the format [LINK]?voyageCode=[ROUTE CODE][VOYAGE NUMBER]
My HTML knowledge is pretty outdated, and I've never worked much with forms. Can anyone advise on how I can construct this?
Why don't you use a select tag for the dropdown and a classic input text for the route coude ?
Then for the link part, you should capture the click event on your button through onClick and then call a small function that'll basically do that :
function concatRouteCode(){
var select= document.getElementById("routeCodeLetters");
var routeCodeLetters = select.options[select.selectedIndex].value;
var routeCodeNumber = document.getElementById('routeCode').value;
return routeCodeLettres+routeCodeNumber;
}
If you really want to combine the codes into a single query parameter, you'll have to use Javascript to fetch the values of the two fields and change the location. You don't need Javascript if you put the values into separate parameters, as in ?routeCode=xx&voyageNumber=123. In that case you would just give the select element the attribute name=routeCode and the input field the attribute name=voyageNumber.
In case you want to go with the first approach, you'd have something like
document.getElementById("idOfSubmitButton").addEventListener("load", function() {
const routeCode = document.getElementById("idOfSelectElement").value;
const voyageNumber = document.getElementById("idOfInputField").value;
location.href = "base URL here" + "?voyageCode=" + routeCode + voyageNumber;
});

Google Forms discrepancy

When I add a list item to a Google Form I can set and get choices.
If I select a list item from an existing form I cannot.
items = form.getItems();
for (i=0;i<items.length;i++){
Logger.log(items[i].getType());
if (items[i].getTitle() == 'A List'){
choices = items.getChoices();
}
}
I can see the items are of type "List" in the log but getChoices throws an error
TypeError: Cannot find function getChoices in object item....
Is this a bug in Apps Script? Is there something I can do to cast the item and make sure it is of the right type?
Thanks
Jeremy
Please reffer to the documentation here. As you can see an item does not have a .getChoices() method. This method is available in specific types of items, like ListItem. So you need to specifically do something like
choices = items[i].asListItem().getChoices()
Remember that items is an array and you need to specify which item you are getting choices for. You then need to specify what type of item it is (i.e. a list item) and only then you can get the choices. If this is something you need to do for any type of item, then you will need to figure out how to check what kind of item it is and then get it as that item type.

Need Validation on html dropdownlist with data from Viewbag

I know I'm not supposed to use the Viewbag and that I should build a menu using Html.DropDowlListFor() so that i can add attribute bound to the members of the model, BUT, that would involve a pretty extensive code rewrite....
I have a custom controller with a menu:
*.ASCX
<%: Html.DropDownList("CityIDs", new SelectList(ViewBag.cities, "Id", "Name"), "--Select--", new { style = "width:200px" })%>
<%= Html.ValidationMessage("CityIDs") %>
The List populates just fine and I can default to the top item to "--Select--"
The prbolem is that I want the validation error to occur on anything that is not from the viewbag.... how can I achieve this?
Validation for dropdown lists only ensures that something was posted. If you want to ensure that the value that was posted is actually one of a set of "allowed" values, then you'll have to manually do that in your post action:
var cityIds = db.Cities.Select(m => m.Id);
if (!cityIds.Contains(model.CityIDs))
{
ModelState.AddModelError("CityIDs", "You must select one of the available choices.");
}
if (ModelState.IsValid)
{
...
Two things:
Notice that I'm pulling the city ids straight from the database (the actual code you'd need here, of course, depends on your specific implementation). The important thing, though, is that ViewBag only survives a single request, so you can't look for them in ViewBag after posting.
Despite the pluralized name of CityIDs, using the DropDownList helper ensures that only a single selected value will exist. If this is actually supposed to be a multiselect, then you need to use ListBox instead, and update this conditional here to account for check for multiple values.
Populates the top item with Text = "--Select--" and Value = ""
which will post a blank value for CityIDs and cause an error in ModelState.

Making HTML elements access a dynamically generated value

So I am making a data entry program where the user presses buttons to generate new inputs (numbers text etc.) and when finished the lists are generally between 100-10000 items.
The program has been coming along well, but now I am at a point where one set of data entered must generate the coices for an array [1,2, . . .] which is part of a later set of data.
So what I have done is setup buttons with the ID based on the earlier inputs. (The whole data set is saved as a JSON)
And what I want to do is when the button is pressed it looks pressed and writes to an HTML element the ID of the button which will later be read and saved to JSON.
My problem is centered on getting the correct information back to the user.
function doStuff(container){
for (var u = 0, c = someJSON.length; u < c; u++){
var someButton = document.createElement('button');
someButton.id = someJSON.id;
someButton.className = 'someButton';
someButton.onclick = function() {
writeIDToHTML(container,someButton,someButton.id);
}
container.appendChild(someButton);
}
}
function writeIDToHTML(container,theButton,theID){
console.log("theID")
console.dir(theID)
}
This prints only the last ID in the loop. How do I get each ID to each button?
The other thing to do is to give the button a pressed look.
Bonus points if it is reversable.
You should not add a listener on each element. The way to do it is adding a listener on the container and get the id of the clicked event (via event.target). This is called event delegation.
I could explain it, but this guys made a perfect answer to your question : http://davidwalsh.name/event-delegate
Btw, you should consider using a library like jquery to manipulate your DOM. It implements event delegation and advanced cross browser DOM manipulation utilities. For instance, you would not need to add a 'container' property since you can access it by the parent() method.

HTML form doesn't contain a form submit button name when using the Enter key

My ASP.NET MVC 3 website has code on the server side that checks for the name of the submit button clicked to submit the form. The code works when I use the mouse to click the button, but when I use the Enter key, the form gets posted, but the request doesn't contain the name of the submit button.
Is there some attribute I can set on the submit button to get this to work for both clicking and using the Enter key?
Here is my HTML:
<div>Search:</div>
<form action="/Item/Search" method="post">
<input class="fulltextsearch" id="FTSearchText" name="FTSearchText" type="text" value="" />
<input type="submit" value="Go" name="FTSearchButton" />
</form>
</div>
On the server side, I have a custom model binder that uses the following code to determine if the user clicked the submit button.
// See if the value provider has the required prefix
var hasPrefix = bindingContext.ValueProvider.ContainsPrefix(bindingContext.ModelName);
var searchPrefix = (hasPrefix) ? bindingContext.ModelName + "." : string.Empty;
var searchButton = GetValue(bindingContext, searchPrefix, "FTSearchButton");
// If this value doesn't have value, the user didn't click the button so exit
if (string.IsNullOrEmpty(searchButton)) {
return null;
}
private static string GetValue(ModelBindingContext context, string prefix, string key) {
var result = context.ValueProvider.GetValue(prefix + key);
return result == null ? null : result.AttemptedValue;
}
Here is the problem I'm having with this. I have a page that displays a list of items. I have a 'search' textbox and a submit button in an HTML form. When the user enters text in the textbox and clicks the search button or uses the enter key, the page posts the form data via HTML GET, and returns the first eight records found. The page then displays page links for additional pages. The problems is that when the user clicks a page link, the form data is all blank, and my filter information is lost (the form isn't posted with the form value when using these links). So, I end up displaying a blank list of items (blank searches returns zero results) instead of paging the data.
By adding the check for the button name in my form data, I could determine whether or not to simply page the data, or do a new look up.
I wouldn't rely on this. There are plenty of documented bugs with this scenario. Just add a hidden field with name='submit'. That way it wouldn't be too hard to recode the backend.
<input type='hidden' name='submit' value='FTSearchButton'/>
So, I researched this last night and almost got somewhere. Then this morning, I really did get somewhere and here's where I ended up.
Apparently the W3C standards for form submission are pretty lax when describing the functionality as it relates to the Enter button and submitting forms. It seems they determined that
When there is only one single-line text input field in a form, the user agent should accept Enter in that field as a request to submit the form.
So that leaves a lot of wiggle room for the browser makers. Today, virtually all browsers support using the Enter key to submit a form, whether the form contains one or more single line text input boxes.
The problem I'm having is more or less unique to Internet Explorer, and only when the form contains one, single-line text input control. For whatever reason, Microsoft decided that when Internet Explorer submits a form like this, it doesn't include the submit button's name/value pair in the post body. However, it does include the button's name/value pair if the user clicks the submit button --or-- uses the Enter key, and the form contains more than one single-line text input control.
So, the only solution I can think of or find suggested is to add a second single-line text input to my form, and then set the the style to
visibility: hidden; display: none;
My form now has two single-line text input controls, so the form will post with the name/value pair in the form body, regardless of whether or not the user used the Enter key or clicked the submit button.
So, we have a workaround that was discovered by ASP.NET developers. It seems the key/value pair is required by ASP.NET web-forms to fire the click event, so this work around isn't something new, albeit not my favorite way to do things.