I need an independent Cross Browser Javascript Library to handle location.hash. not jQuery Specific. not dojo.hash. and if thats makes use of HTML 5 thats always welcome
In lieu of native hashchange support (IE8+, FFx 3.6+, WebKits from 528+), you'll need to poll the location hash for changes.
I don't know about any lib, but you can use a cross-browser function to handle the location.hash and then integrate it into your desired lib.
You could use the watch property implementation to act as an observer over the "document.location.hash" object. Then, the syntax would be something like :
window.location.watch(
'hash',
function(id,oldVal,newVal){
console.log("the window's hash value has changed from "+oldval+" to "+newVal);
}
);
if you want to do it this way, not to wait for an existing library to implement their own cross-browser method, I find the "watch" method as a very good start. You can see disscutions on this topic here.
This has all you need:
The All-In-One Entirely-Not-Alphabetical No-Bullshit Guide to HTML5 Fallbacks
You can see different libraries under the Browser State Management section.
For a good hash change library see this one: History.js
Related
I want to use timezone-js in my app, but I'm not Fleegix.js, which "just works". The readme says to look in the spec file for an example, but it looks like that uses Node.js stuff. Is there a way to make a load for Jquery or just raw JS or something?
I got confused on those docs also. It's not quite clear, but jQuery support is already built in. You just have to set async to false to get it to work. Not sure why - since ajax is async anyway - but that's the flag to set to get it to work with jQuery. No other wireup is needed.
timezoneJS.timezone.zoneFileBasePath = 'scripts/tz';
timezoneJS.timezone.init({ async: false });
Also - there are other libraries that do the same thing. You may find one of these more appealing.
How do you disable pushstate for Chrome (for testing purposes)?
Bonus if you know of a plugin that makes it easy to toggle :)
I'm using davis.js for my pushstate logic.
history.pushState = function (){};
//An empty function so if it is used, it doesn't throw any errors
Put that in the console. Tada! You can easily make a Chrome extension that executes that on a page using a Content Script.
The reason your Davis.js routes are still working is because when you click a link it runs your routes directly, since there is no onPushState event, you should find though that using the back and forward buttons no longer trigger your routes.
If you want to emulate what happens in a browser that doesn't support pushState you can fool around with how Davis.js checks for support. This is done in the Davis.supported function.
You can override that function to always return false, which is what would happen normally in a browser that doesn't support pushState. If you wanted to you could wrap this up into a Davis.js extension, see the block iOS extension as an example.
I am bulding a webpage using xPages and I am making constant changes to script and design, this include both server and client javascript , stylesheet and image changes.
Each time I change a javascript or stylesheet I want to see my changes in the webbrowser and I also want my users to get the latest changes when they access the webpage.
I know I can use Shift-Reload, or CTRL-reload and clear my webbrowser cache. and I also know that I can change the objects expiration date, but I want a smoother and better controlled way to do this.
Looking for any kind of best practice for doing this.
Thanks
Thomas
In the xsp.properties file for the application or on the server for server wide use you can set xsp.application.forcefullrefresh=true. The xsp.properties file documentation says:
# Application refresh
# When this property is set to true, then a full application refresh is requested when
# the design of a class changes (means that all the data are discarded in scopes).
# xsp.application.forcefullrefresh=false
The new XSP Portable Command Guide says "This property was introduced in Notes/Domino 8.5.3. It is set to false by default and is particularly useful during the development phase of an XPages application."
I have not fully tested this behavior but it sounds promising. You could/should of course only set it to true WHILE you make the changes. once stable, set it back.
/Newbs
Adding to Ferry's answer and your comment;
Instead of "?dummy=randomvalue", you can use "?version=2.1". So it will be cached but when you change design, you can just increase the version.
There's a problem with this approach as some proxy servers won't cache anything with query params. Better to rename the file directly, adding date or version number to it. It will always work.
To disable caching temporarily use Fiddler2. It's easy to enable and disable in one place across any web client. As well as added benefits for the http request tracking features.
To fully disable any caching add url + '"?dummy=" + #Unique();' to every url to javascript or image files...
The way I am reading this question is that you want every change you make to appear immediately on the client's browser or client. Are you really sure you want to do this? It sounds like you are not doing any testing so any typos, bugs, crashes, etc will be passed on to your users. Sounds like a bad plan to me. I hope I am wrong and that you are using a template and pushing only your fully tested changes up to an production version instead of making the changes in the production version.
I would just put out a schedule of when changes are going to be pushed up to production and let the users reload their browser or client at that time. Either that or do it during off hours and when they next log on, they get the newest changes.
Adding to Ferry's answer and your comment;
Instead of "?dummy=randomvalue", you can use "?version=2.1". So it will be cached but when you change design, you can just increase the version.
maybe you could look at how domino can control caching of url's.
http://www.ibm.com/developerworks/lotus/library/ls-resp_head_rules/
NEwbs answer is a good one but it is useful to note that in Firefox there is a very useful plug in called "web developer" from Chris Pederick that allows you to disable the cache.
http://chrispederick.com/work/web-developer/
The other really useful one is Firebug which is just amazing - It makes any HTML work much easier
https://addons.mozilla.org/en-US/firefox/addon/firebug/
I did found another solution by putting my css and js in a theme it is easy to just rename the files.
as described here
http://goo.gl/vFTii
Why do not we use the window.location.reload()...
Which does the same like ctrl+F5
It reloads the page, which is similar to context.reloadpage
First of all I am new to javascript so this question might be stupid.
I have a requirement where i would provide a js script to other websites to include in their webpages.
Now my question is should I use jquery or plain javascript.Will/Can jquery effect the rest of the functionality of the site.
Plus what is the benefit I will get using jquery over plain javascript.
My requirement is to get all images of the website and do some processing on the images on these websites.
Thanks in Advance.
I would say, if the processing does not involve jQuery then do not use it.
You need to deal with the following issues if you include it
failure to load (for network reasons)
conflict with other versions locally loaded
conflict with other libraries locally loaded
All issues have workarounds/solutions but you have to implement each an everyone of those.
If you just need to find all images in page, then you can use the .getElementsByTagName() method
var imagelist = document.getElementsByTagName('img');
and just do the processing on that..
You might need of-course to attach your code at the load event to be sure that whatever your code does, the DOM is ready to accept it..
for modern browsers that would be .addEventListener(), while for IE it would be .attchEvent()
your script could be something like this
(function(){ // wrap in a self-invoking function to avoid global name-space pollution
// attach to the load event so out code runs once the page has loaded
if (window.addEventListener) { // modern
window.addEventListener('load', imageProcessor, false);
}
else if (window.attachEvent) { // IE
window.attachEvent('onload', imageProcessor );
}
function imageProcessor(){
// get all images
var imagelist = document.getElementsByTagName('img');
// loop the list of images to do something with each image
for (var img = 0; img < imagelist.length; img++)
{
var currentImage = imagelist[img];
// do processing on the currentImage which hold a reference to the image
}
}
})(); // do the self-invoking
demo: http://jsfiddle.net/gaby/nXPzk/
this would be much more easier to achieve with jQuery, mostly because you want to be able to distribute your script to any browser(and jQuery is a cross-browser library), but it does have it's downsides.
If it's your own project, your own page, you know exactly what and when to load/execute, but if you're giving your script to other folks, you have to think of 3 problems at least:
different libraries conflicts
This can be resolved using jquery's noConflict method, but I've seen it fail in some circumstances
same library conflicts
Say that the user already has loaded version X of jQuery. You oblige him to load version Y too, and besides the fact that this would be very inefficient, it may cause conflicts between different jQuery versions.
There are workarounds for this( to check if jQuery exists and load it asynchroniously if it doesn't) but the code gets a bit more complicated.
code size
When i think of a third party piece of code, I'm thinking...hmm a few kb to load to be able to run a function, but if you want to use jQuery, you may be forcing the one who uses your script to load a whole library just for your one functionality instead of a 1-2 kb (needles to say what the implications are if the user has a slow connection)
Having both the ups and downs in mind, it really depends on what are you doing, so, as Gaby aka G. Petrioli said, " if the processing does not involve jQuery then do not use it".
JQuery is much more convenient than plain javascript. You don't have to worry about cross-browser compatibility (e.g. IE vs. Firefox vs. Chrome). I would recommend this over javascript unless you are want to handle that yourself :)
You can load in the Jquery library, but that might be a little heavy than what you're looking for. Also, you will need to fetch the library from a server, which adds another point of failure (however, if you host this on your own server, then you will have more control).
TLDR: JQuery is convenient. If you have access to it, then you should use it.
I have just been altered to the fact that a user of my website is using a very old browser which does not run jquery (in this case Safari 1.x) and as a result can not access the login panel which uses jquery's slideToggle function.
Can anyone think of a fix which detects whether a browser is able to use jquery - and if not make that link go to a different page rather than showing the login panel?
You could a little conditional check like
if(!'jQuery' in window) {
// jQuery is not available
}
or, if Safari 1.x doesn't know about the IN operator (I'm not sure) use
if(!window.jQuery) {
}
I think there are alternative answers to this, but for me, I would have to weigh up the time it will take you to support his obsolete browser (I'm sure there may be other things inside the site), versus the payback to you...
In the plain HTML source code for the the href= of the login link, set that to a plain HTML login page.
Using jQuery, attach the click handler to the link, if this part fails, thats ok, the browser will just follow the href in the link to the plain login page, allowing your old-browser-user to login still.
$(document).ready(function(){
$('#login_link_id').click(function(){
// Your code here
});
});
If you use javascript/jQuery you should ALWAYS ensure your site works perfectly without it. In this case if you have a login popup box; you probably assign a click event assigned after the DOM has loaded.
What you should do is ensure that if jQuery isn't present the link loads a "normal" login webpage as opposed to the popupbox. I use something similar to this:
Log in
<script>
if(!'jQuery' in window) {
$(document).ready(function(){
//assign on click event to loginlink
});
}
</script>
If jQuery doesn't exist then login.html will be opened normally.
Wow, seriously?! Safari 1.x?? Anyhow, try this...
var isJQSupported = false;
$(function() { //shorthand for document.ready
isJQSupported = true;
//your usual code
});
if (!isJQSupported) {
window.location = "http://www.apple.com/safari/download/";
}
To me it sounds like safari 1.X has problems with jQuery internally. Which means simple checks like whether $ exists in the global space or whether $(function) does anything are not going to help.
The most likely root cause will be that javascript throws an error in loading of jQuery itself which will then stop the rest of your javascript code from execution.
There are four viable options here.
Either make the website work with noscript. Replace your login control with pure HTML and postbacks and ask the user to turn javascript off. This option is useful since you won't be fixing the issue for safari 1.x problems specifically.
You can make javascript check for safari 1.X and other non-supported browsers and only load jQuery through script tag injection or ajax if your user is using a supported browser. If the user is using a browser not compatible with jQuery then you can instead use plain javascript.
Get a copy of safari 1.x and see why jQuery breaks. Then fix it and ask for it to pulled into the release of jQuery 1.5. This relies on the fix being something that does can be done without hacking and that the jQuery team agrees is worth adding in.
Ask the user to use a compliant browser.
There might be some more options. I would personally lean towards asking the user to use a compliant browser because supporting Safari 1.x is ridiculous.
This seems like a case where progressive enhancement is needed.
You have to do multiple checks
see if $ exists
see if $.fn exists
[not sure if needed] check if $.support is a function
check for feature support as needed with $.support() http://api.jquery.com/jQuery.support/
At the end of the check, when jQuery reports that features you need are present - the rest of the script can run.
If you're not sure which features mentioned in the support you use, then this might need a single test on Safari 1.x to see what are the values returned by $.support(), but that is what your nasty old-browser-user can do for you (if you prepare code and publish) and report the resulting text. Then you compare the list with other [old] browsers that are accessible and determine features that are required.
The easy way would be to require everything and cancel all scripts if suport for any feature is missing. This will also rule out IE6 and IE7 and opera below 9.something and firefox below 2.0 or including - I'm not sure.
Use a server side language to detect if it's the old safari based on user-agent and load a different javascript file