I've come across a peculiarity with EditorFor() helper in MVC 3.
I have a form view that is strongly type (trimmed down):
#model GoGoLegal.Models.Address
#using (Html.BeginForm())
{
#Html.ValidationSummary(true)
<div>
#Html.EditorFor(model => model)
</div>
<div>
<input type="submit" value="Post" />
</div>
}
and I have an Address EditorTemplate.
When the Input Button is click without anything in the fields then Validation gets thrown, however when there are values in the fields and the Input Button is clicked then nothing happens.. at all... It doesn't hit the controller, both HttpWatch and FireBug don't even register the event. I'm wondering whats happen.
I've also tried to replace
#Html.EditorFor(model => model)
with
#Html.EditorForModel(Model)
And still the same thing.
Any thoughts on this?
Have you tried clearing your cache. Sometimes a cached version of the page gets confused. Try Ctrl-F5 after you've loaded the page, then see if the page posts.
Also, look at your code and make sure there aren't any malformed tags. That can also confuse the browser, maybe you don't close everything.
Also check the actual HTML in the browser with a "View source" and see if the HTML looks correct.
Related
I'm doing a browser check and trying to display a warning message if the person is using a browser that is not compatible(IE 8 and less), believe me, there are people using it where i work
The problem i'm having is i cannot seem to hide the #Render of the page
My if statements are all kicking in fine, and i have wrapped the #Render with a div and i'm trying to hide it based on the conditions i get, like so
else {
$("#yourMessage").show();
$("#content").hide();
}
HTML
<div id="content">
#RenderBody()
</div>
<div id="yourMessage" hidden="hidden">Some Message</div>
Is there something built in to MVC to stop me from being able to do this?
I've noticed that browsers do not store form values until the form is submitted, which means that if you're using AJAX instead of a standard form submit, your browser's auto-fill is never populated. Is there a way to force populate your browsers auto-fill/auto-complete so that I can have this convenience with forms that are submitted via AJAX? It's annoying to go to my AJAX page and have to type in the same things in the form fields every time because the browser doesn't remember them.
My question is pretty much identical to the this one, except that only a work around in FireFox is provided as the accepted answer to that question. I'm looking for a solution that works in all major browsers (at least Chrome, FF, and IE), if there is one.
Note: I am not talking about AJAX auto-complete plugins, which is what almost always pops up when googling this question. I am talking about your browser's built-in auto-complete or auto-fill that helps you fill out forms by remembering what you entered in the past.
For anyone who's still trying to solve this, seem like I've found the answer.
Chromium tries to recognize the submit event, even if you preventDefault and handle the actual submission yourself.
That's it, you need to preventDefault the submit event, not the click event.
This worked on Chrome, Edge and IE 11 at the time of writing (I'm too lazy to download and test it on Firefox).
Here's your form:
<form method="POST" id="my-form">
<label>Email</label>
<input autocomplete="email" type="email" name="email">
<button type="submit">Subscribe</button>
</form>
Notice the autocomplete attribute. These are all the possible values that you can use for autocomplete.
In JavaScript, simply do this:
$("#my-form").on("submit", function (ev) {
ev.preventDefault();
// Do AJAX stuff here
});
The browser will remember whatever email you've entered on clicking subscribe button.
I have also come across this; there doesn't seem to be a great solution, certainly not a cross browser one, but here is one for IE I haven't seen anyone mention:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<SCRIPT>
function subForm()
{
window.external.AutoCompleteSaveForm(f1);
f1.submit();
}
</script>
</HEAD>
<BODY>
<FORM id=f1>
User ID : <input type=text name=id></input><br>
Password :<input type=password name=pw></input><br>
E-mail :<input type = text VCARD_NAME = "vCard.Email"> <br>
<input type=button value=submit onclick="subForm()">
</FORM>
</BODY>
</HTML>
From: http://support.microsoft.com/kb/329156
Use this Method:
AutoCompleteSaveForm = function(form){
var iframe = document.createElement('iframe');
iframe.name = 'uniqu_asdfaf';
iframe.style.cssText = 'position:absolute; height:1px; top:-100px; left:-100px';
document.body.appendChild(iframe);
var oldTarget = form.target;
var oldAction = form.action;
form.target = 'uniqu_asdfaf';
form.action = '/favicon.ico';
form.submit();
setTimeout(function(){
form.target = oldTarget;
form.action = oldAction;
document.body.removeChild(iframe);
});
}
Tested with ie10, ff latest, chrome latest
Test yourself: http://jsbin.com/abuhICu/1
Have you try the answer of my question that you mention?
The answer is using hidden iframe but seems he claim the idea is not working on IE and Chrome on that time.
Try to take the idea, and instead of using hidden iframe, just put the username/password/submit visible input element in a form POST, in an iframe. So user will enter login details directly into iframe. With proper Javascript you can put loading image, get success or denied from server and update the parent or the whole page. I believe it should work on any browser.
Or if you still want to use AJAX since you probably implemented the API on server side. You can make the iframe to just send a dummy POST at the same time send the real user/pass to AJAX URL.
Or back to use hidden iframe, not to hide it but move it to the invisible area like top: -1000px.
After several hours searching, I found a solution at Trigger autocomplete without submitting a form.
Basically, it uses a hidden iframe in the same page, set the action of your form to the 'src' of the iframe, and add a hidden submit button inside the form, when user clicks your button which triggers AJAX requests, you should programmatically click the hidden button before sending the AJAX request. see example below:
In your form page:
<iframe id="hidden_iframe" name="hidden_iframe" class="hidden" src="/content/blank"></iframe>
<form target="hidden_iframe" method="post" action="/content/blank" class="form-horizontal">
<input type="text" name="name">
<input type="text" name="age">
....
<button id="submit_button" type="submit" class="hidden"></button>
<button id="go_button" type="submit" class="hidden">Go</button>
</form>
Then java script:
$('#go_button').click(function(event){
//submit the form to the hidden iframe
$('#submit_button').click();
//do your business here
$.ajax(function(){
//whatever you want here
}})
);
Hope this helps.
I've got a simple AJAX POST form set up in a jQTouch application. We're talking out-of-the-box simple here:
<form id="contact" class="topPage" method="post" action="/process/mobile-submit.cfm">
<!-- Various form guts go here -->
</form>
And this works just great. My users punch in their info, my server-side script does its job and gobbles up the lead data and spits back an out-of-the-box simple response.
<div>
<div class="toolbar">
Back
</div>
<div class="info">
<strong>Thank You For Your Submission</strong><br />
We have received your inquiry, and blah blah blah jibber jabber.
</div>
</div>
Everyone's happy... except those of us who are trying to track the conversion in Google Analytics. Now, I've got virtual pageviews set up on each panel in this application using the pageAnimationEnd event, which is easy as pie when you know what selectors those are going to be attached to in advance, but when jQTouch creates a new segment from the form return, it has a generic serialized ID like #page-N.
I've tried adding a loose script block into the form return. That works fine for Firefox on my desktop, not so much for Safari on my phone.
Since I've allowed jQTouch to handle the AJAX particulars for me in this instance, is there a straightforward way to attach a success handler to it? Or am I better off trying to bind a pageAnimationEnd handler on $('[id^=page-]') and hope the business doesn't want me to do anything else with ad hoc form returns until we replace this app with one written in jQuery Mobile?
Worked it out.
The return fragment can declare its own ID, naturally, and jQTouch will then treat it as though it were an original part of the document. I had previously assumed jQTouch didn't give a toss about what attributes I gave the fragment; I was wrong.
This means that you could goTo it like any other portion of the document. It also means that you can bind a pageAnimationEnd handler on the return fragment either by ID or by class name and it will behave as expected. Thus:
<div class="formResult">
<div class="toolbar">
Back
</div>
<div class="info">
<strong>Thank You For Your Submission</strong><br />
We have received your inquiry, and blah blah blah jibber jabber.
</div>
And:
$('.formReturn').live('pageAnimationEnd', function(evt, info) {
if (info.direction == 'in') {
// Goal completion code
} else {
$(this).remove();
}
});
This is lengthy, yes, I apologize. But I want to be clear because this issue is so odd.
I have a terms of service modal that comes up whenever a user has not accepted our terms of service (TOS). For the purposes here, javascript is turned off and what is rendered is strictly html/css. So the page, if thought of in 3 layers, is: bottom layer = page they came to see (i.e. an event page), middle layer: a semi-opaque overlay, top (primary/visible) layer: a modal with the terms of service agreement form in it. This form is simply an accept checkbox and submit button.
I noticed that the TOS was not working properly, but at seemingly random times. Then I noticed that it was broken but only on my event page (/event/foo) even though the same partial is responsible for showing the terms of service agreement no matter where they show up on the site. So for any other page, like /group/bar, the same TOS modal would show up and would work fine.
I then realized that the problem was that the form tag was missing from my HTML! Just gone.
So, taking a step back, the (HAML) code in question is simply:
%div#accept_tosC
%b Before form_for
- form_for #current_user do |form|
%b After form_for
%div#tosC= render :partial => 'general/terms'
%div.left
= render :partial => 'shared/user/tos_form_element'
%div.right
= image_submit_tag "/images/buttons/submit_100x20.png", :id => 'submit', :name => 'submit'
For our /events/foo page, the generated HTML look like this:
<div id="accept_tosC">
<b>before form_for</b>
<div style="margin: 0pt; padding: 0pt;"><input type="hidden" value="put" name="_method"><input type="hidden" value="44c2bf7a64fc59baa3fc7129167f0e2c3e96abb6" name="authenticity_token"></div>
<b>after form_for</b>
The obvious question here is if 'Before form_for' and 'After form_for' make it into the document, why doens't the form tag form_for creates?
For a different page, say /groups/foo, we get exactly what we would expect:
<div id="accept_tosC">
<b>before form_for</b>
<form method="post" id="edit_user_595" class="edit_user" action="/users/595"><div style="margin: 0pt; padding: 0pt;"><input type="hidden" value="put" name="_method"><input type="hidden" value="44c2bf7a64fc59baa3fc7129167f0e2c3e96abb6" name="authenticity_token"></div>
<b>after form_for</b>
I tracked it down to a single partial well inside the code for the "bottom" layer (the page they requested, not the TOS overlay). This partial in question may or may not be viewable to any given individual so we have to check if the user can view this page. The result of that is held in the variable can_view:
:ruby
#some processing to set page info and can_view
return unless can_view
%div#statsC
...and so on...
This is what my code looked like and the form tag did not render. By making the following change, the form element tag showed up as expected for all pages:
:ruby
#some processing to set page info and can_view
- if can_view
%div#statsC
...and so on...
So here is the question: Why would returning from a partial prevent a form element tag from becoming part of the document?
The short answer is that templates work in mysterious ways, and return is just generally not safe to use within them.
The long answer is that, behind the scenes, templates are compiled into Ruby methods that build up a string of HTML code and return that code. I'm guessing that by returning without returning the proper code, you're making something go haywire and discard the string that the form_for is concatenating to.
I am having a strange issue in Firefox 3.5.2 with F5 refresh.
Basically, when I focus on an input field and hit f5 the contents of that input field gets copied to the next form field after the F5 refresh.
But, if you inspect the HTML source code, the values are correctly loaded.
I am not having this issue in IE8 or Safari 4.0.3.
The problem does not occur if I do a hard refresh or run window.location.refresh(true).
After F5 Refresh: http://i805.photobucket.com/albums/yy339/abepark/after.jpg
Here's an overview of what's going on.
I believe the thing you should look into is the autocomplete attribute,
you should set it to off on the input box. However be careful since this will trigger two effects.
When you refresh the page it won't remember the old values
The default dropdown of the already used values on that input box will also be disabled.
If you want to keep the second behavior you should set the autocomplete attribute back to on with JS.
Browsers can remember form field contents over a refresh. This can really throw your scripting off if it is relying on the initial value of a field matching what's in the HTML. You could try to prevent it by calling form.reset() at the start.
Different browsers have different strategies for detecting when a form or a field is the same as in the previous page. If you have clashing names, or names that change on reload, it is very possible to end up confusing them. Would have to see some code to work it out for sure.
In the backend, I am using ASP.NET MVC 1.0 with the Spark View engine. When I examine the source code after an F5 refresh in Firefox 3.5.2, the page renders correctly; however, if you look at the page visually the adjacent form field field gets populated with the value from the previous field.
I included enough code so you can just get an idea of what I'm trying to do.
Again, the rendering is fine and the final view/HTML code is fine. It's what I see on the screen that is incorrect. I am using hidden vars; but the issue occurred before using it as well.
Note in the code below, I have 2 distinct ID fields: "date_{projectTask.ProjectTaskId}" and "finishDate_{projectTask.ProjectTaskId}, which gets renders to something like "date_1" and "finishDate_2".
<table>
<for each="ProjectTask projectTask in projectTasksByProjectPhase">
<input type="hidden" value="${projectTask.ProjectTaskId}" />
<tr>
<td class="date">
<div class="box">
<div class="datefield">
<input type="text" id="date_${projectTask.ProjectTaskId}" value="${startDate}" /><button type="button" id="show_${projectTask.ProjectTaskId}" title="Show Calendar"><img src="~/Content/yui/assets/calbtn.gif" width="18" height="18" alt="Calendar" ></button>
</div>
</div>
</td>
<td>
<div class="box">
<div class="datefield">
<input type="text" id="finishDate_${projectTask.ProjectTaskId}" value="${finishDate}" /><button type="button" id="finishShow_${projectTask.ProjectTaskId}" title="Show Calendar"><img src="~/Content/yui/assets/calbtn.gif" width="18" height="18" alt="Calendar" ></button>
</div>
</div>
</td>
</tr>
</for>
</table>
FYI: ${} are used to output variables in the Spark View engine.
I am also using the YUI 2.7 Connection to make Ajax calls to update the datebase for "change" and "enter/tab key press" events. I am able to verify that the AJAX calls are made correctly and the form field values are still valid.
The problem occurs when I just do a F5 refresh; for some reason, the "finishDate_1" gets populated with the value from "date_1".
This problem occurs just by clicking on "date_1" and hitting F5; so, the adjacent field just gets populated even if there are no AJAX calls.
Here's the Javascript code I call towards the end of the body"
YAHOO.util.Event.onDOMReady(
function() {
var idList = YAHOO.util.Dom.getElementsBy(function (el) { return (el.type == 'hidden'); }, 'input');
len = idList.length;
var startDatePickers = new Array();
var finishDatePickers = new Array();
for (var i = 0; i < len; i++) {
var id = idList[i].value
startDatePickers[i] = new DatePicker("date_" + id, "show_" + id, "cal_" + id);
startDatePickers[i].valueChanged.subscribe(updateDate, 'S');
finishDatePickers[i] = new DatePicker("finishDate_" + id, "finishShow_" + id, "finishCal_" + id);
finishDatePickers[i].valueChanged.subscribe(updateDate, 'F');
}
}
}
The form field gets copied over before any Javascript code is processed because I call the Javascript code towards the end of the body after all HTML is rendered. So, I'm guessing it's a refresh issue in Firefox? What do you guys think?
As you can see above, I created my own calender date picker objects which allows you to either enter the date in the text manually or by clicking on a button to view the calendar and select a date. Once you enter or select the date, an AJAX call will be made to update the datebase in the back end.
Thanks everybody for the quick responses.
#Anonymous: whoever you are, you are awesome!
#bobince: thanks for the feedback as well.
I added a dummy form tag with the attribute autocomplete="off" and that solved the problem!
I was scratching my head because I didn't get this issue in Safari 4.0.3 or Internet Explorer 8.
<form action="" autcomplete="off">
<!-- my code -->
</form>
The values were loading correctly in the back end (ASP.NET MVC 1.0/Spark View engine) and the HTML source code reflected this, but the input field values were not getting populated correctly. I was using the YUI Connection Manager and Javascript to support edit-in-place and the date pickers.
I tried changing the XHR call to a GET call instead of POST and the same issue was happening.
Anyway, the problem was that the Firefox was not setting the correct values for the input fields for F5 refreshes.
Again, thanks so much! You guys rock!
All element id's must be unique, if two elements have same id's then that could be reason why Firefox inserts same values to elments that didn't orginally have those values entered.
I had a similar problem related to my question at Input control shows incorrect value, even 'though inspect element shows the right value is there
The problem occurred for me in Firefox, but not Chrome, for some but not all controls on the form, and when I pressed F5, but not ctrl-F5.
The "dummy form" seems to have resolved it for me.