I notice my site does not have a single <form> with the exception of logging in. I am not sure how or why it happened but i found i use jquery and ajax to post everything then refresh (or not if i dont need to). How and why would the user suffer from this?
Some of my 'forms' include
Leaving a comment on a page
Removing messages
Sending a private message (which i then do document.location=nextPage)
Marking as a favourite.
Forgetting for a moment that none of the site would work without javascript disabled, another side effect you might not realize, is that there is no default submit behavior anymore. This means a user cannot finish typing their entry and hit enter to submit the form. This is important for search forms and the like, but less important for comment forms.
Wrapping form fields in a form tag and having a submit input element (even if it is display:none) allows for a default submit action on enter or return. If you do this, you simply call preventDefault() into the submit() event handler to stop the real submit, and make an AJAX one instead.
Ok, back to the JS disabled thought. You have to make a choice:
Work backwards to implement unobtrusive JS on your site. Basically, the site works with or without JS, but it will work better (or more refined) with JS enabled
Or place a prominent message alerting your users to the fact that your site requires JS for the site to work. The cons to this method is you might limit the usefulness of your site in some corporate networks and on some mobile devices. As far as people who willingly turn of JS, the alert can let them decide if they want to stay around or not.
Given that the site is already coded, take a look at your target audience and make your best decision given the time and energy required to make the site work without JS.
From your comment, I see that you don't intend to support users without JavaScript, so the accessibility and backward compatibility argument is moot.
However, you are likely creating a lot of unnecessary requests by posting with AJAX and then refreshing the page. This is not how AJAX was intended to be used and is possibly an anti-pattern. The idea of AJAX is to send specific and receive specific data, and to update the page based on that received data, not refreshing.
Also, by not using form's, you disable the default submit functionality (pressing <enter>) as Doug Neiner pointed out
Related
I was wondering if there is some cleaner way to implement event firing on input tag value change (i want it to fire every time character is entered/deleted) and make these values visible in controller other than using ajax?
So the way I know now is implementing JavaScript snippet which would attach addEventListener to input element (like here) and would make ajax call to initial rails controller to pass the new input tag value. However ajax feels like too much as opposed to if there would be something native in rails, I just can't seem to find it.
If you need anything from browser going out to server (written in any language) without refreshing the page, Ajax is the way to go. Now-a-days, fetch would be another alternative, which works in similar manner.
If you need every key-stroke to be sent to server (controller), you should add a keyup event listener. In the event listener function, make an Ajax/fetch call to the endpoint, and return relevant information from your controller.
Do remember to include a timestamp in the requests, and send them back in response though. In most such scenarios, you'd want to be differentiate between "what is new" vs "what is stale", in case user types too fast. Due to network delays, responses typically do not come back in same order as the requests were made in.
I need to capture telemetry information that captures details such as when the user opens a form, closes it or navigates away from the form.
To do this, I have javascript calls to a telemetry api. In the case below, when the user navigates away or closes the tab, I would like to trigger "mymethod" which will call the api method to capture this event.
I am trying to trigger a javascript method when the user navigates aways from the form. I have this script which is on the CRM form. The below code does not work.
window.onbeforeunload = function() {
console.log('onbeforeunload triggered...');
mymethod();
return true;
};
Ideally I would like to be able to detect when the user navigates away from the page, or closes the page. Any suggestions appreciated. Thanks in advance.
This will probably never work - that type of code within CRM is unsupported.
Microsoft Dynamics 365 and the importance of staying supported.
Microsoft provide a set of tools and guidelines describing the things
we can do, they also tell us the – unsupported – things we shouldn’t
do. It’s all on the MSDN. Un-supported scenarios that commonly occur:
All JavaScript interactions within the application pages must only be performed using functions defined in Xrm.Page & Xrm.Utility
namespaces, i.e. don’t directly interact with the page DOM.
I would suggest asking a new question which focuses on your end goal. You have told us something that doesn't work (but we wouldnt really expect it to) - you havn't actually told us what you are trying to achieve.
I don't understand how does ECMAScript works. Check on MSDN and other forum it didnt tell us which version or values equal to javascrpt.
if (!Request.Browser.JavaScript)
//Do Something.
However, I was given a warning of obsolute and recommend me to use ECMAScript instead.
System.Web.HttpBrowserCapabilities myBrowserCaps = Request.Browser;
if (((System.Web.Configuration.HttpCapabilitiesBase)myBrowserCaps).EcmaScriptVersion.Major < 1)
//Does not have Javascript. Do something.
However, I tried both on/off my javascript. Somehow the function was not fired. I suspect certain values belong to javascript. However, I cant find anything related to value == javascript.
I understand I could a Then perform a redirect using meta tag. But I would like all these code to perform at the server.
First of all, see Should I bother to develop for JavaScript disabled? / How important is graceful degradation of JavaScript? .
Then, client-side Javascript only exists in the client and if it's off, no client-side logic will fire to check anything explicitly. So you cannot know it until the client sends at least one reply from your page (be it a GET/POST query or an XMLHTTPRequest) - i.e. only after the second request from that very user, generated by the very page you sent them, which may never occur if they just lurk around, even if you make every link on your page a form reply - they may use URLs from an external source. A CodeProject article linked from Check if javascript is disabled? is one example of such approach.
For this reason (and to avoid effort duplication to make both script and noscript versions - the practice that saw some use in the past), the best practice appears to have become making pages and frameworks JavaScript-agnostic and just warning the user with <noscript> that the page may not be fully functional if it's relevant.
E.g. Sharepoint does just that - with JS disabled, a warning appears on top while on the page, there are e.g. no scrollbars and editing is disabled completely. Which leads to conclusion that ASP.NET controls (which SP makes heavy use of) weren't designed to be functional beyond basic display with JS disabled in the first place.
When we have some controls in ASP.NET, it's of course preferable to use both clientside and serverside validation. Clientside for usability purposes, and serverside for security purposes.
However, this easily gets quite ugly. Of course, if your validation is a length check or a regular expression, it is easy to maintain. However, let's say that your validation is more advanced - what to do?
One way is to implement the exact same functionality in both server code and Javascript. Another way is that both calls a webservice with the same logic, but then your AJAX call has to be synchronous which in general is bad practice.
So, my question is, what's the best way to perform both serverside and clientside validation?
Your ajax call does not have to be synchronous for validation; it just needs to be quick:
When the user tabs off a field, say, an ajax call is made to the service and the field displays a spinner next to it, indicating the server is validating the data.
If the service returns success, the spinner is replaced by a green check mark.
If the service returns failure, a red X, perhaps with explanatory text.
When the user finally clicks submit, the same validation takes place on the server (synchronously or not).
Another option (besides #user133811's of using JS is both places) is to find a cross-compiler, which will compile your language of choice into JavaScript. These may or may not be available, however.
I've generally found that doing complex validation on the client is unnecessary and undesirable. Yes, let me know a field is required, or if a username exists (via ajax), or simple things, but if this is a complex mortgage application or something, I expect I'll have to submit before finding out I need to include my W2 if I declare my pet goldfish as co-signatory (or whatever, you get the point).
the same code for server and client would mean that your server needs to use JS. Node could be something you could potentially use.
I want to implement a 'live search' or 'search suggestions' feature in a web application that uses the Dojo Framework. It would be similar to the way Google and Bing searches display matches as you type: when you type in the search box, a list of potential matches appears below. Searches would be performed server side, with the results sent back to the browser using AJAX.
Does anyone know of a good way to implement this using Dojo?
Here are some potential options:
The built-in widget dijit.form.ComboBox
This has very similar functionality, but I've only seen it used with limited data sets. The examples always use small lists (such as the 50 states in USA) and preload the entire data set for client-side filtering. However I presume I could hook it up to a dojox.data.JsonQueryRestStore for server-side search — can anyone confirm whether that works?
QueryBox http://marumushi.com/code/querybox/
This implementation mainly does the job, but it has some minor bugs and doesn't look like it's being maintained. I'd have to do some bugfixes on the code before using it.
Medryx http://blog.medryx.org/2008/09/10/dijitsearch-part-2/
This also looks like it does the job, but it is described as 'alpha-level' code and the link to the code seems to be broken...
I could probably make one of the above work, but I'd like to know if there are any better alternatives out there.
I implemented it 5 years ago when Dojo was at 0.2:
http://www.lazutkin.com/blog/2005/12/23/live-filtering/
While the code is ancient, it is trivial, and hopefully it'll give you ideas on how to attack it. The rough sketch:
Attach an event handler to your input box, which is triggered on changes — use "onkeyup" to detect a change in the input box.
Wait until user stopped typing by setting a timer in your event handler, if it is not set yet. 200-500ms are good waiting times.
The timeout plays a dual role:
It throttles our requests to a server to prevent overloading.
It plays on our perception of time and our typing habits.
If our timeout is up, and we don't wait for a server ⇒ send server a string we have so far.
If we are still waiting for a server, cancel the request and ask again.
This part is app-specific: we don't want to overload a server, and sometimes a server cannot handle broken connections well.
In the example I don't cancel the XHR call, but wait it to finish first before submitting new request.
Server responds with relevant results, which are promptly shown.
In the blog post I implemented it as a widget. Obviously the exact packaging is up to you.