I need assistance determining what is doing client side validation on a site.
There is a web form on a site, and it does some client side validation on a field labelled Email (named Question2). This is the page: http://www.home-energy-analytics.co.uk/concrete5.6.1/index.php?cID=132.
If you add a "1" to the email field and then change the focus to another element, you'll see the border turn red. If you try to submit the form, the client prevents it, and shows what looks like an absolutely positioned div with the text, "Please enter an email address". It doesn't seem possible to inspect this element using firefox or firebug. I have checked all the inline scripts and those in separate files, but cannot see what is doing these validations.
It looks like there may be a script which is created dynamically by the client using the ccm_addHeaderItem function in the ccm-base script, but I cannot see how that function is being called, in order to work out the URL of any dynamically created script.
Are you able to find the function(s) doing these validations?
Note, as this is a concrete5 site, I have asked on the concrete5 forums without success.
This is a HTML5 feature. It will be implemented by browser default behavior.
Check the example here http://www.w3schools.com/html/tryit.asp?filename=tryhtml5_input_type_email
This behaviour can be seen anywhere for a input field with type "email"
I am working on a project that use MVC 2.0 with Kendo UI. We decided to use AJAX validation instead of MVC Model level validation; which means validation happens during most "onchange" events on HTML controls. We coded the red CSS "highlight" on HTML controls when error happens and remove the highlight when there is no error. If there are multiple controls (e.g. checkboxes) we will highlight all of them when error occurs...and of course, error messages related to multiple fields validaton....
We get it sort of working but we had to implement a lot of javascript/jQuery coding on each web form page (including control id/name matching on the validation message) and does not seem to be able to implement it as a common routine against all web forms. We are also wondering if there is some sort of validation library already out there that more or less achieving the same thing...
Any suggestions?
If you tag your question with kendo-ui you are probably using it so it might be worthy taking a look into kendo.ui.Validator
You should try jQuery Validation
Its very easy to use, but you do still need to link each input to they type of validation required
Philosophical question:
Say I've got a web app that requires javascript and a modern browser, so progressive enhancement is not an issue. If my form is being built via javascript, and my data updates are all being done via ajax POSTs & PUTs, is there really any reason to wrap my controls in a form tag? If I'm still going to use the tag, say for semantic or structural reasons, is there any reason to have action and method params that I'm going to ignore? It kind of feels like a hold-over from an earlier era to me.
There is at least one important user-experience feature provided specifically by wrapping inputs inside a form tag:
The enter key will submit the form. In fact, in Mobile Safari, this is how you get the "Go" button to appear on the keyboard.
Without a form wrapping the inputs, there is nothing to submit.
You can of course provide enter-key behavior through a keypress event, but I don't know about if this works for mobile devices. I don't know about you, but I'd rather work with the semantics provided by the browser than have to imitate them with events.
In your case, you would simply provide an onsubmit event handler for the form, which would do your AJAX submit, then return false, canceling the actual submit.
You can simply provide action="" (which means "self"), and method is not required — it defaults to GET.
If you do not need progressive enhancement, you theoretically don't need them.
On the other hand, forms have some cool grouping and semantic effects. Using them, you can group your form elements logically, and make it easier for your scripts to gather the values of certain elements.
For example if you want to ajax-submit some user input, it is always easier to say: "let's take all elements in this form and submit them" than saying "let's take this input, these two selects and these three textareas and submit them". In my experience, it actually helps the developer if form tags are present.
AJAX is great but as JamWaffles (+1 to him) said, using form tags provides a fallback method.
Personally I use form tags, even for things I submit with AJAX because it is syntactically clear and makes it easy to grab all inputs within a specific form. Yes you could do this with a div or whatever too but as I said, using a form is syntactically nice.
Incidentally, screen readers treat the content inside a form differently so there are accessibility issues to be considered whichever way you choose to go. Note that anecdotal evidence suggests that Google considers accessibility in its rankings so if SEO is a concern for you, use a form and do it right.
Summary:
forms OK for MVC, simple web apps, bad for component oriented, rich web apps.
Reason:
forms cannot nest other forms: big limitation for a component-oriented architecture.
Details:
For typical MVC applications, forms are great. In rich, complex web applications using a lot of javascript and AJAX and with a lot of components here and there, I don't like forms. Reason: forms cannot nest another forms. Then if each component renders a form, components cannot nest each other. Too bad. By changing all forms to divs, I can nest them, and whenever I want to grab all parameters in order to pass them to ajax, I just do (with jQuery):
$("#id_of_my_div").find("[name]").serialize();
(or some other filtering)
instead of:
$("#id_of_my_form").serialize();
Though, for sentimental and semantic reasons, I keep naming my divs something_form when they are acting as forms.
Not that I can see. I'm currently building a web application that uses <form>s, but I'm using them so I have a fallback method if the user has JavaScript disabled (an e.preventDefault stops the form posting normally). For your situation, where you're saying the user MUST have JavaScript, a <form> tag isn't necessary, but it might be an idea to keep it anyway in case browser need to do anything with it, or to access it as a sort of class.
In short, no, you don't need to use <form> if you're doing pure AJAX, although leaving it in might an idea if you suddenly decide to create fallback code in the future.
In my opinion: If you use it for semantic reasons, then use it as intended. The action attribute is required (also can be left empty) to be well-formed, also you can separate your URI-s from your js logic, by setting the action attribute, and reading it before the ajax call.
I don't see why you would need to use the form tag here. The only reason to use a form tag (other than to get your markup to validate) is if you are going to have the user "submit" the data using a sumbit input or button tag. If you don't need to do that, then there is no need for the form. However, not sure if it will be considered "valid" markup. If you do use it you can just do <form action=""> as action is the only required attribute of the form tag. However, you do bring up a good point, the future of web applications probably will no longer need the form and traditional submit methodology. Very interesting, and makes me happy. hehe :)
Is it possible to fire a JavaScript method after a form element is considered invalid? Here is my scenario:
There are 2 tabs on the ASPX page. The user has to fill out info on both tabs. The user, while on tab 2 clicks the submit button. However, there is a required field on tab one that needs attention. Do I need to create a custom valuator (either a CustomValidator control or create a new control from the base valuator) to call a JavaScript function to display tab 1 and show where the error is?
Unfortunately, the canned Field Validator controls in ASP.NET Webforms are not very extensible. I've had needs to change the CSS class of an input field to an invalid state upon client-side validation, and I never found a good way to handle this.
I think your best bet might be to do your own client-side validation. I've also looked into this third party product and it seemed to be pretty fully-functional, but I couldn't justify the cost in my case: http://www.peterblum.com/DES/Home.aspx
You can call any js function from your server side code after the validation check on page object and inside the js function you can write the logic to highlight the field which has issue on validation:
if(!Page.IsValid)
{
Page.ClientScript.RegisterStartupScript(typeof(Page), "validate", "myjsfunction();", true);
}
else
{
// type code here
}
I am looking for some help autosaving tinyMCE. I want to save the content within tiny into its respective textarea after content has been updated. So that when I make an ajax call the content is in the textarea ready to be posted.
Currently I have this little bit of code but it only updates the text area when you press a button in tiny (like bold, italics, underline, etc). I also have the link where I found the code. Any help would be appreciated.
$('.AjaxEdit textarea.tiny').tinymce({
//other init options
//need this function to save tiny data before Ajax call
//http://www.webmasterkitchen.com/article/tinymce-ajax-form-submission/
setup : function(ed) {
ed.onChange.add(function(ed) {
tinyMCE.triggerSave();
});
}
});
You're best bet is to adjust your AJAX call so it pulls the content straight from TinyMCE or triggerSave just before the AJAX call rather than trying to constantly have the textarea in sync with the editor content. Serialising and filtering the entire document so it can be stored on every change is a major performance hit.
If you really need to keep the textarea in sync, you'd have to add DOM modification listeners to the document in the iframe that TinyMCE creates to store the content - you can retrieve it with the getDoc() function (see http://tinymce.ephox.com/documentation/api/index.html#class_tinymce.Editor.html-getDoc). You are going to have major performance problems here though.
Regards,
Adrian Sutton
http://tinymce.ephox.com
Though the question is quite old, I've came accross while searching for a plugin. At the end I've implemented my own plugin.
I have written a plugin that sends the form data to the specified url every x seconds. I have blogged it here.
In short, the idea is to create an iframe, change the target and action of the form dynamically, and submit the form to stimulate an ajax effect. Once saved, I am putting the form element into its initial state so that if the user wants to save manually he or she will not have any difficulties.
Please note that the plugin I've written is for tinymce4. You'll have to change the source code a bit for older versions.
You should take a look at this autosave plugin http://code.google.com/p/tinyautosave/
FYI, I have done it like this:
$('textarea.wysiwyg').tinymce({
...
onchange_callback : function(inst) {
// Prints the DOM element (textarea) to the console.
console.log( inst.getElement() );
// Prints the content of tinyMCE to the console.
console.log( inst.getBody().innerHTML );
}
});
Official documentation on the onchange_callback event