I'm using the nifty 'combobox' variant of jQuery UI Autocomplete - see here: http://jqueryui.com/demos/autocomplete/#combobox
I have it within a Form element because its part of a form.
The Autocomplete Combobox has a <button> that is used to show the whole drop down list. However when the user presses it, the form submits. This appears to be because the <button> has a type="submit" attribute. The whole element is created by the button() call within the .combobox fn, see source code.
How do I stop it submitting?
(NB: This guy had the same problem but he fixed it by removing the form - I can't do that)
Ah, nevermind, I figured it out.
The problem is discussed on the jQuery forum here:
http://forum.jquery.com/topic/autocomplete-combobox-problem-when-it-is-placed-inside-a-form-tag
They suggest several different ways of adjusting the source code of the autocomplete combo to fix it. The simplest one seems to be this:
Change the line that says
$("<button> </button>")
to
$("<button type=\"button\"> </button>")
this prevents the type="submit" from being inserted into the final button.
Related
Is it possible to fire action,actionListener of a <p:commandButton> with attribute type="button". I have a requirement where in a form there are text boxes and command buttons. If I press enter in any text box then commandButton is invoked. So I change all command buttons type to "button". Now problem I am facing that command button's action, actionListener not firing.I want to solve it with out using java script. Also I read this This Link. Can any one tell me where I should edit or change to get expected output. Thanks.
Using type="button" is the wrong solution to prevent enter key from submitting the form. It basically changes the submit button to a dead button which does not submit the form and is only useful for attaching JavaScript onclick and likes. You're simply facing the consequences of this wrong solution. You should not try to fix it, but take a step back and solve the initial problem the right way.
One of the ways is:
<h:form onkeydown="return event.keyCode != 13">
Or, more generically, with jQuery, which skips textareas from the restriction:
$(document).on("keydown", ":input:not[textarea]", function(event) {
return event.keyCode != 13;
});
Note: jQuery is already bundled in PrimeFaces, you do not need to install any scripts separately. Also note that you really can't go around JavaScript here. Even more, PrimeFaces/ajax components rely on JavaScript and wouldn't work anyway without JavaScript.
I've been using jQuery UI with Bootstrap and I seem to run into a problem that I haven't had before. I'm not sure what has changed; I've tried setting back different version of jQuery and I didn't update the jQuery UI in the meanwhile. So I'm not exactly sure what broke.
The error from the console when I click on any date in the datepicker returns:
Uncaught TypeError: Cannot set property 'currentDay' of undefined
The code is fairly straightforward as one would expect from a datepicker:
$(".datepicker").datepicker({
dateFormat: 'dd-mm-yy'
});
With the following HTML:
<input type="text" class="datepicker" />
Is this a bug that should be reported (since no other Google matches turn up) or is it something else I've missed?
I've found the solution. After a long time of debugging I figured out that there was a <div> that had the exact same ID, lying higher than the input field. Therefore the script took the first instance that contained the ID and picked the DIV instead of the input field.
I removed/renamed the DIV and it worked fine again.
The above jQuery datepicker error is generally caused by having a duplicate controls with the same ID, no matter whether you use id or another selector like css class or field name to instantiate it.
I solved this with create new ID for HTML DOM object. There is duplicated Id.
Try to add new ID for HTML DOM object.
I was having this error also. I found that elsewhere on the form I had some label 'for' attributes that did not match ids on the form inputs - seems like this might confuse datepicker too. Once I fixed those up, everything worked fine and the error went away. Take Andreas' advice (+1 for that!) and validate your forms - Chris Pederick's Web Developer Toolbar gives you an easy way to validate as you go.
put a selector.
<script> $("#formID #duplicatedId").datepicker({language: 'he'});
</script>
FormID: Id of the form that contains input.
duplicatedId: input element's Id.
In my case I was triggering the datepicker from a div against a hidden input field and getPos(a) was causing an undefined message on the variable "a". I experimented with moving the hidden input field outside of a div and that did the trick. Note that the input field was findable by jQuery no matter where it was, so that was not the problem - it was with positioning. Hope this helps someone else.
Might be two input box having same class without different id and for that you are trying for date picker. If it is there give two different id it will work.
I've ran into this problem too, and i was 100% sure i did not use duplicate id.
After some debugging i found out a reason - i was using DataTables mod, which duplicates contents of tfoot, thus creating exact copy of datepicker elements. And i had this datepicker inputs in tfoot row.
Fixed that issue with:
table.find("TFOOT").find("TR:first").remove();
Which is called AFTER table.DataTable(....)
This removed original, zero height row with all contents;
Select boxes converted to Select2, do not automatically integrate with unobtrusive validation mechanism in ASP.NET MVC framework.
For example, on a form which contains a regular select box (marked as required in model definition), submitting the form while no options have been selected in the select box, will cause the border and background of the select box to take a reddish color, and by using #Html.ValidationMessageFor, error messages, if any, can be displayed beside the box. However if the select box is converted to a Select2 component, then none of the mentioned features work any more. Even the validation error message will not show up.
It seems that the reason for even the validation error message not showing, is because Select2 changes the display CSS property of the original select box to none (display:none), and I guess the unobtrusive validation script does not bother generating error messages for invisible fields.
Any ideas / solutions?
This issue isn't really specific to Select2, but rather to the jQuery unobtrusive validator.
You can turn on validation for hidden fields as highlighted in this answer.
$.validator.setDefaults({
ignore: ''
});
As the comments noted, it didn't work inside an anonymous callback function within $(document).ready(). I had to put it at the top level.
I've run into similar issues with the select2 plugin. I don't know exactly which features you're using specifically, but in my experience, when you set an element as a select2 in the document.ready event, the plugin will change some of the element's attributes on the fly (inspect one of the elements after your page has finished loading - oftentimes you'll see the id and class properties are different than what you're seeing when you view source).
It's difficult to offer more without actually seeing the code, but here's a few ideas to get you started:
First off, obviously make sure you have the a link to your select2.css stylesheet in the header.
Then, since you're talking about form submissions, I'd recommend you examine whether or not you're getting a full postback or submitting via AJAX (if you're using jQueryMobile, you're using AJAX unless you override it in the jquerymobile.js file or set a data-ajax="false" in your form attributes). You can just look at the value returned by Request.IsAjaxRequest() for this. Obviously if you're submitting via ajax, you won't hit the document.ready event and the select2 won't initialize properly and you'd need to figure out a way around that. Try refreshing the page after the submit and see if it renders the select2 component.
Then I'd suggest examining the elements and see if they're not behaving like you'd expect because you're actually trying to work with classes that the plugin has reassigned at runtime. You can either just adjust your logic, or you can dig into the select2 code itself and change the behavior - it's actually fairly well-documented what the code is doing, and if you hop on the Google group for select2, Igor is usually pretty quick to follow up with questions.
like this
$('select').on('select2:select', function (evt){
$(this).blur();
});
$('body').on('change', 'select.m-select2', function () {
$(this).blur();
})
I am using Django and the django-dynamic-formset plugin to generate a JQuery Mobile (JQM) site. I have nested forms that allow the user to click a "Add" link to another line to the form. This works great without JQM, but when JQM is used to style the form widgets the radio button labels do not trigger the correct radio button.
I have put up a static example of the behaviour, based on the generated HTML. Click the "Add" link, then try choosing a severity for the added item. The "for" attributes of the labels appear to update correctly, so I do not know what I'm doing wrong.
The django-dynamic-formset guide provides me with a way to call a JavaScript function after the user clicks the "Add" button, but I do not know if there's a JQM method I should be calling that will fix the issue. When I use JQM's enhanceWithin function it triggers a page load, which submits my form to Django, which I don't want at that point because the form won't validate yet.
Edit: I uploaded a much better example to the same URL.
After enough caffeine and peanut M&M's I have figured it out.
Reason for Failure: The django-dynamic-formset (DDF) plugin duplicates the form you give it. But the form is cloned as-is, which already includes all the JQuery Mobile (JQM) processing. This causes JQM to ignore it and makes the radio buttons misbehave.
The Solution: The DDF plugin allows you to specify what form to clone by its formTemplate parameter. JQM allows you to disable automatic mobile-enhancement of certain elements. Create an un-enhanced version of your form, and pass that to DDF as your formTemplate.
More Details:
I put this coded into my HTML head, before the reference to JQM:
<script>
$(document).bind('mobileinit',function(){
$.mobile.ignoreContentEnabled = true; // required for using the natural forms
});
</script>
And included this style to hide my "natural" form:
<style>
.natural-form { visibility: hidden; display: none; }
</style>
In the Django code I added a <div class='natural-form> and put a dummy version of my form in it (being sure to surround it another <div> with a unique ID for reference later). In my initialization of DDF I give it the unique ID as the parameter to formTemplate.
I was told on another forum I would have to hack DDF and JQM to get this to work. I am impressed at the design of both of these libraries - flexible enough that a newbie to JQuery can stick all the pieces in the right places and get something out of it.
I have a problem in IE. Hitting enter when the focus is on the last input control sends the focus to the "Next" button. This submits the form. So far, so good.
The code in my base class WizardController looks to see if the Next submit button is null, as follows:
protected string NextButton
{
get
{
return ControllerContext.HttpContext.Request.Params["NextButton"];Nex
}
}
However, despite the form submitting, this property returns null unless the user explicitly clicks on the button with his mouse.
This is blatantly wrong, but I have no idea why it is happening.
EDITED TO SPECIFY THE PRECISE PROBLEM:
The problem only occurs IF there is ONLY one TEXT input control in the HTML form that gets rendered to the browser.
END EDIT
Andrew
I have finally found an explanation for my problem:
It seems to be a bug in IE, whereby if there is a single text input in the rendered HTML form, then IE will not submit the form properly. The issue is described (briefly) at:
Form Submit via Enter Key when using IE
In the above link, no description is given as to why the bug occurs, or since what version of IE, so a blanket solution is better.
The workaround suggested in the article is to add a css hidden text input (with conditionals for IE):
<!--[if IE]>
<input type="text" style="display: none;" disabled="disabled" size="1" />
<![endif]-->
This worked for me, so issue solved.
The following is included to document the issue as I experienced it:
Unlike the problem described in the article, my form did submit. However, when I tried to check which button had been accessed by hitting tab or enter key, no submit button was in the HttpContext.Request.Params collection. So the behaviour I saw was slightly different.
What the above article did identify is that this behaviour is only seen WHEN there is ONLY one text input control. A single check box, for example, does not cause the problem.
I hope that this documents the problem adequately... and that MS will one day correct the bug.
A simple work around might be to use a hidden form element and depend on that rather than the button.
<input type='hidden' name='action' value='next' />
If you have multiple buttons you can always use JavaScript to change the value of the action element just before submitting.