I have lots of javascript alerts throughout my site, I need to style them up using a jquery dialog. Can anyone please tell me how I can setup a default dialog and populate it with the alert text?
A typical alert looks like this:
window.alert(“text here”);
My current dialog looks like this:
$('#sessionTimeout-dialog').dialog({
autoOpen: false,
width: 400,
modal: true,
closeOnEscape: true,
buttons: {
"Log Out Now": function () {
window.location.href = o.logoutUrl;
},
"Stay Connected": function () {
$(this).dialog('close');
}
}
});
Can I set the defaults such as width and close on escape so I don’t have to keep adding them for each instance, there are literally hundreds.
Are you asking if it is possible to change the behaviour of window.alert(), so that it opens in your jQuery dialogue instead of the browser’s native alert box?
Sure has.
We’ve just got to work out how to monetize it and we’re made
I thing something like jQuery UI Dialog is the way to go, but I understood the question to be that he has a load of alerts (hundreds) and he is looking for a way to have them appear in jQuery modal by just flicking a switch.
As far as I know the only way to convert them is by hand (or with a scripting language if you have access to the source files).
Anyway, maybe I misunderstood the question, so pray enlighten us Sir mattastic.
You can always assign a new function to window.alert in order to override the one built in.
Getting the code to pause at that point and not run the following code straight away is more difficult. I worked out a way to altomate the rewrite of the script where all of the code is executed sequentially but loops makes it far more complicated.
You could but you shouldn’t. I don’t recommend this at all.
JavaScript has no class concept. As such, private member, access modifiers and so on, are not found in the language (you can emulate those now using IIFEs and you should be able to do it soon, with ES6). This enables one to replace practically any object property (remember, almost everything in JavaScript is a object, window is a object and alert is a method property for window).
Because of that, there is no protective mechanism for Array, or Function. One could replace these constructor functions and completely change the way JavaScript works.
However, when it comes to replacing existing objects and properties, the rule is… don’t. Especially when it comes to the native part. Namespaces and modules should be on your mind, not replacing or extending the native objects.
Well, if the OP would hijack windows.alert, and a third party library it uses would also hijack the windows.alert, and another third party library it uses would also hijack the windows.alert, the site functionality soon starts to resemble a black hole where no one can tell for sure what happens inside.
Anyway, until the OP points the site, for me it’s not clear what its intentions are.
Given that window.alert(), window.confirm(), and window.prompt() now serve no purpose whatever in JavaScript the only danger in overriding them is as you say if multiple scripts were to override them.
By overriding them LAST in the JavaScript you attach to the page you can ensure that your particular choice of how they are overridden would take precedence.
No library should be using any of these long dead calls so the only time you’d have the sort of problem you are suggesting is if you are using an antiquated library - but they would be unlikely to be trying to override any of these obsolete methods because when the antiquated library was written the method wasn’t obsolete.
Given that no modern library would use any of these, it should be reasonably safe to override them for your own use.
The situation would be entirely different if the discussion was about JavaScript built in methods that are still used. The argument you put forward for not overriding built in methods definitely applies to all of the ones that JavaScript still uses.
The only reason that overriding alert() can be considered is that it is long obsolete. The last browser to require its use in live scripts was Netscape 4 and now that all browsers have a built in debugger it is no longer needed for debugging - so there is no longer any circumstances where it should be used - unless you override it with your own replacement.
Only by those still writing their JavaScript with Netscape 4 as the target browser. Just because people still use long dead code doesn’t mean that they should. Unfortunately there are still a lot of people who don’t understand the difference between JavaScript for Netscape 2, JavaScript for Internet Explorer 5 and JavaScript for modern browsers - which are effectively three completely different languages as things have changed so much between them.
Whenever I used to see an alert I always checked the box to turn off JavaScript as I assume the web page has supplied that alert so as to give me that option. I don’t see them any more as I turned those long dead calls off in my browser. Now my browser completely ignores any alert() confirm() or prompt() call as it assumes that they were left in the code by accident as such calls ceased to be needed in live code about 10 years ago when Netscape 4 died.
Anyone who uses alert() in scripts now need to take a JavaScript 101 course to learn the basics of how to write JavaScript for modern browsers.
alert() was replaced by console.log() and the built in debugger last year when Firefox finally added a built in debugger (as all the other browsers already had one).
Just because there are still people writing JavaScript for Netscape 2 or for Internet Explorer 5 doesn’t mean that they are writing code that is going to work in modern browsers. That it is trivially easy to turn off alert() confirm() and prompt() completely in modern browsers means that using them is now completely pointless. That they display extra checkboxes in browser that cam out a couple of years ago made their use for anything other than debugging pointless.
Interestingly enough, they are right in using window.alert instead of just alert, as a sign that they respect native JavaScript and expect others to do too. Meaning don’t hijack it, create your own.
Two highly representative sources, and in sections with advanced topics.
And I’m 100% sure the “Hello World!” starter program in JavaScript it’s still alert(“Hello World!”).
You keep coming back to alert as a debugging method. It’s not, at least not recently, not with IE8 Developer Tools, or Firebug, or DragonFly, and certainly not now, with Chrome DevTools or Brackets.
You keep coming back to Netscape 4. I believe that this is a big big stretch. You should just drop it. The web and JavaScript world too have moved way beyond this.
The only reason that those commands haven’t been flagged as obsolete in the JavaScript standards is that they have never been a part of the standard in the first place. You can’t remove commands from the standard without adding them first.
No - that’s what it was 10 years ago as the replacement for document.write(‘Hello World’);
Now the Hello World starter program for JavaScript uses innerHTML instead as the following two tutorials show.
Mixing up bad practice (innerHTML for adding content) with seriously unreliable sources (I mean, you’re attempting to trump my Microsoft and Mozilla with your w3schools! COME ON!) is really not helping your argument.
Especially when your own w3schools is using alert for Hello World!
Security considerations
It is not uncommon to see innerHTML used to insert text in a web page. This comes with a security risk.
However, there are ways to execute JavaScript without using <script> elements, so there is still a security risk whenever you use innerHTML to set strings over which you have no control.
For that reason, it is recommended you not use innerHTML when inserting plain text; instead, use node.textContent. This doesn’t interpret the passed content as HTML, but instead inserts it as raw text.
Security Warning: Improper handling of the innerHTML property can enable script-injection attacks. When accepting text from an untrusted source (such as the query string of a URL), use createTextNode to convert the HTML to text, and append the element to the document using appendChild. Refer to the Examples section below for more information.
alert is a toy everybody agrees and understands. Reason enough to not hijack it. Which is the point from which I got sidetracked with code politics nonsense and debugging techniques misdirections.
W3 Schools is still in the process of replacing antiquated pages such as that one. The page I linked to is the very first script they offer and is one that they have updated. I only linked to that to show that even really antiquated sites such as w3schools are getting rid of their alert() pages now.
I’ll trump the Microsoft and Mozilla sites with the ECMAScript standards site - which does not acknowledge that JavaScript has ever had an alert() command. Since that site is THE standards for JavaScript it is the final word - http://www.ecma-international.org/ecma-262/5.1/ - try searching the standards for alert() and you will not find a single reference to such a command ever existing.
alert() is a proprietary command that used to serve a useful purpose in JavaScript but which only ever served a useful purpose in live web pages in Netscape 2 through 4 and Internet Explorer 3. More recent browsers reinvented it as a debugging tool by adding extra checkboxes to what gets displayed but even that use of it has been superseded by the proprietary console.log() command.
Even this recent SitePoint article about “Promises” has example code using alert() http://www.sitepoint.com/overview-javascript-promises/
I think in part it’'s because old habits die hard and part because it’s being used during development.
That is, it’s still a “quick and dirty” way to see what’s going on with the code without needing to open up a console.
As far as trying to style alert() for production use I wouldn’t bother, there are much nicer alternatives available.
A search for console in the ECMAScript standard also returns nothing. This is not because console is regarded as obsolete or because it has passed its days as a useful tool.
In addition to the properties defined in this specification the global object may have additional host defined properties.
Both alert and console fit in this category. This is to say that the ECMAScript specs accepts alert or console existence, and, even more importantly, the ECMAScript specs will NEVER decide about alert or console or any of the like, for that matter.
There is no normative committee watching over alert and deciding it’s obsolete.
The only one declaring alert dead, for all intents and purposes, is you. This may be true for you, but it doesn’t make it so for the rest of the world.
The only thing that changed is the programmer perception. Which should include, for you too, following best practices and NEVER hijack existing properties and object, but instead, create your own, in your own namespace and module.
As you can see from the above - some browsers include an option to turn off JavaScript in all their alerts and others provide an option for turning off subsequent alerts.
Given this their use for anything other than debugging or in examples is now impossible as you can’t control when these additional checkboxes will be displayed. This means that they are dead as far as using them in live web pages is concerned
As most people want control over how the dialogs they display to their visitors look they cannot use alert() confirm() or prompt() for this purpose anyway as there is no way that the person coding the page can get rid of the checkbox for turning off their JavaScript. Building your own alternatives where you have complete control over how the dialog looks is relatively easy.
Use of these dialogs in debugging scripts or as placeholders in example code is still possible but better alternatives now exist such as using console.log which doesn’t leave messy debugging dialogs in your live script if you miss removing one before making the script live.
They may not be totally dead in testing and example code but they are dead in so far as live web pages are concerned - at least they are if you want the code after the alert to run and not have the person visiting your page make use of the checkbox in the alert to turn off JavaScript for the rest of the page.
Personally I prefer not to see left over debugging statements and so have turned them off in my browser. As they can be easily turned off in all modern browsers there’s no guarantee that they will be seen at all by your visitors - another reason to not use them.
The OP was asking about how to style their alert calls to look the way they want. The only way to do that is to either replace the call with custom code or to override that method with your own custom one. Given that different browsers display alerts etc differently from other browsers there’s no reason in this instance why overriding it to use your own custom appearance is unreasonable. The alert call will still be displaying a dialog - just one that looks how you want it to look rather than the dozens of different ways that it will display normally depending on the browser that is being used. It isn’t like all the browsers have the same code in their built in alert function - only by overriding it can you get all the browsers to behave the same way when it is called.
You are a little off here. When the alerts have a high repeating rate, ONLY THEN is the user presented with that option. This is to prevent infinite alert loops which would block the browser.
Yes, you will control the appearance. But replicating the scripts execution stopping the native alert features, that’s a thing you yourself have not solved in your replacement you linked to, a few posts up.
No one uses alert to debug these days, or even reasonable distant times, it’s a toy tool, it always has been.
No, that’s precisely the reason for not hijacking the alert. As any native can be easily hijacked, there’s no guarantee that your replacement will take precedence and will be seen at all by your visitors as you intended - another reason not to hijack them.
Hijacking natives also spells out questionable intents from the web site.
And that overriding would make it for a half ass job which would cost any real developer its job. Do it properly, learn to do it properly, or step aside. That’s my opinion.
You seem to be going around in circles with this. I’m going to stop here.
