Just pulled out the old textSnow class foer 1.11 and rewrote it for 1.2.4. Anyway, head over to the demo page, it has all the info you need.
Here’s a novel idea (stolen from AppDen‘s Twitter feed fetch class) – extend the mootools-more’s JSONP class and setup some quick and easy geolocation lookups through pidgets.com and YQL (yahoo query language).
Here they are, 3 mini classes. First one uses the client’s IP address (or an optional ip supplied by options) to fetch geolocation info from http://geoip.pidgets.com/. The second instance fetches extended information on a place / city by location from Yahoo’s geoplaces DB, including things like local district, council authority, county and so forth, something that I find useful when creating quick signup forms for users and PAF lookups are not in the budget. The final class was simple test to fetch relevant timezone info of any latitude + longitude combination. It offers local time, offset from GMT or DST etc, but nothing that Date.get(“gmtoffset”) can’t accomplish anyway).
Request.geoLocation = new Class({
// gets basic info such as country and latitude data
Extends: Request.JSONP,
options: {
ip: $empty(), // default is user but you can lookup anything.
url: "http://geoip.pidgets.com/?format=json",
},
initialize: function(options) {
this.parent(options);
if (this.options.ip.length)
this.options.url = this.options.url += "&ip=" + this.options.ip
},
success: function(data, script) {
this.parent(data, script);
}
});
Request.getPlaceInfo = new Class({
// return json data with extended information of a place / location.
Extends: Request.JSONP,
options: {
url: "http://query.yahooapis.com/v1/public/yql?q=select * from geo.places where text='{location}'&format=json",
},
initialize: function(location, options) {
this.parent(options);
this.options.url = this.options.url.substitute({location: location});
},
success: function(data, script) {
this.parent(data, script);
}
});
Request.timeZone = new Class({
// return local timezone related date from geo coordinates
Extends: Request.JSONP,
options: {
url: "http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20xml%20where%20url%3D'http%3A%2F%2Fws.geonames.org%2Ftimezone%3Flat%3D{latitude}%26lng%3D{longitude}'&format=json"
},
initialize: function(latitude, longitude, options){
this.parent(options);
this.options.url = this.options.url.substitute({latitude: latitude, longitude: longitude});
},
success: function(data, script) {
this.parent(data, script);
}
});
Here is a quick example of how it can be used on a form. Note you need mootools-more with JSONP for it to work.
This is not a tool you can rely on for customer-facing development, but I found it invaluable nevertheless. jsPrintSetup is a small fireFox add-on that hands you a controlling object in javascript. You get FULL access to any print-related function you could think of: list printers, select default printers, print silently, control spool, headers… There’s just too much to mention. Very useful when coding a CMS that needs to print specific things to specific printers (for example, invoices on printer #1 and labels on printer #2).
Here is an example that fetches a list of printers and remembers the user’s preference for future use:
// only do something if the plugin is live
if ($type(jsPrintSetup)) {
var printers = jsPrintSetup.getPrintersList().split(","); // get a list of installed printers
// no print dialogue boxes needed
jsPrintSetup.setSilentPrint(true);
// create a dropdown
var printList = new Element("select", {
id: "printerList",
events: {
change: function() {
Cookie.write("defaultPrinter", this.get("value"), {
path: "/admin/",
duration: 365
});
// save the new printer selection
jsPrintSetup.setPrinter(this.get("value"));
}
}
}).injectTop($("printSetup"));
// get default by preference if any
var defaultPrinter = Cookie.read("defaultPrinter");
printers.each(function(el) {
new Element("option", {
value: el,
text: el,
selected: (defaultPrinter == el) ? "selected" : false
}).inject(printList);
});
// attach an event that prints from an element called goPrint
$("goPrint").addEvents({
click: function() {
jsPrintSetup.print();
}
});
}
It has always annoyed me as a user when having to strain my eyesight and having to type weird letters or numbers in order to prove I am a human. The practice is known as ‘captcha’ and dates back a while now. Regretfully, nothing much has changed aside from the ability of the bots to OCR better – we still need to read some obtuse characters.
This is why I wrote a javascript mootools captcha class called hOOmanTest – making the whole ‘prove you are not a bot’ a lot easier to stomach. Regretfully, it has no degradation as it relies on drag and drop, but you can use reCaptcha inside your target div as the fallback and have the class apply an .empty() before populating it, providing the upper layer.
*edit*: I really do hope it helps somebody, here is the first site that uses it out there–in a quotation webform on the cleaning 4u site, click the free quote banner to view.
This is not much of a post but a bit of a rant. “It’s my party and I’ll cry if I want to”, right?
I have a problem with jQuery–not with the framework as such, but with some of its users. And who in their right mind wouldn’t be getting the amp when just about any webdev site, forum and topic is now full of clever know-it-alls that come and declare how ‘such and such jQuery plugin will do what you want’. There’s always a jQuery plugin for everything, didn’t you know…
Does not matter if the question at hand is on vanilla javascript or mootools, just add jQuery and whistle… Already use another framework? Get jQuery anyway, it’s so good you can run in compatibility mode!
The sad part is in how a large portion of these jquerysts have absolutely no understanding of vanilla javascript. It feels as if some of them inadvertently consider ‘javascript’ and ‘jQuery’ to be synonymous…
Aren”t people just getting carried away slightly? I’ll be the first to admit how jQuery is full of awesome features, documentation and support. Why, it’s so great and so far removed from standard javascript syntax that some go to extreme lengths to mimic its shorthand in other frameworks as well. Just the other, having downvoted a jQuery solution for a mootools question on stackoverflow, I was told how $(“someid”).click(); was a perfectly reasonable and valid mootools syntax (as shown by David Walsh)
Paradoxically, in lowering the standards and requirements (in the sense of, by being too accessible and too easy to use), jQuery has spawned an army of coders that don’t even have to learn javascript. A lot of badly formed code gets released, complete with a disregard for best practices, memory, bandwith use, usability and god knows what else…
Still, perhaps there will come a day when mootools sports a high-spirited in-your-face following. For we have a lot to be tooting about, after all…
I have had the facebook tooltip available as a part of my core library for a while now. However, usage on various sites highlighted certain visual errors in the way it rendered on sites with custom CSS settings for line-height and line-spacing. This (plus the ineffectiveness of the old way the tooltip arrow was injected) caused me to sit down and refactor the whole function. Look at the demo tooltip page for possible uses.
Nathan White announced the mootools 1.2.3 release today. This is to be the last version prior to bumping everything into mootools 2.0.
Although mootools 1.2.3 is mostly about bug fixing, it does introduce an important feature: “Element: MooTools compatibility mode: the $ function is only defined if no pre-existing $ function is found. If an existing $ function is found, you can use document.id()”
In reality this means that mootools will be able to co-exist with frameworks such as jQuery (or others). It will still not work alongside Prototype, for example – extending prototypes just cannot be namespaced. Also, even though you now CAN use more than one framework at a time, you probably shouldn’t do so on the same page, its a wasteful and needless practice.
*update* 15/09/2009 – Added a new option, carousel: true|false, which creates a never-ending wrap of the image set. Check the imageScrOOler example page for more.
I have had this in my pipeline a while now but it’s time to release it for whoever needs this kind of thing. The idea is simple: have an array of images that are scrolling from left to right and right to left in a containing layer with a possible click event that goes to a relevant URL.
Here is an example using some brands and a click through to their respective pages (taken from webtogs.co.uk where the original script for 1.11 resides):
The code used to generate this
// compose your data through PHP or whatever:
var mc, sdata = [{image: '4.jpg', url: '/Berghaus/', title: 'Berghaus'},
{image: '88.jpg', url: '/Big_Agnes/', title: 'Big Agnes'},
{image: '63.jpg', url: '/Brasher/', title: 'Brasher'},
{image: '35.jpg', url: '/Bridgedale/', title: 'Bridgedale'},
{image: '65.jpg', url: '/Buff/', title: 'Buff'},
{image: '3.jpg', url: '/Camelbak/', title: 'Camelbak'},
{image: '6.jpg', url: '/Craghoppers/', title: 'Craghoppers'},
{image: '93.jpg', url: '/Crumpler/', title: 'Crumpler'},
{image: '39.jpg', url: '/Deuter/', title: 'Deuter'},
{image: '86.jpg', url: '/Haglofs/', title: 'Haglofs'},
{image: '71.jpg', url: '/Helly_Hansen/', title: 'Helly Hansen'},
{image: '95.jpg', url: '/Icebreaker/', title: 'Icebreaker'},
{image: '92.jpg', url: '/Inov8/', title: 'Inov8'},
{image: '61.jpg', url: '/Jetboil/', title: 'Jetboil'},
{image: '31.jpg', url: '/Keen/', title: 'Keen'},
{image: '97.jpg', url: '/Kuhl/', title: 'Kuhl'},
{image: '48.jpg', url: '/Trangia/', title: 'Trangia'},
{image: '42.jpg', url: '/Vango/', title: 'Vango'},
{image: '44.jpg', url: '/Vaude/', title: 'Vaude'},
{image: '52.jpg', url: '/Victorinox/', title: 'Victorinox'}];
window.addEvents({
domready: function() {
mc = new ImageScrOOler(sdata, {
imagePath: "http://www.webtogs.co.uk/brands75/",
imageHeight: 85,
targetElement: $("scr"),
clickEvent: function(obj) {
window.location.href = "http://www.webtogs.co.uk" + escape(obj.url);
// can use a lightbox or whatever instead - for example, if your obj has a property .largerImage,
// you can modal / largerBox it instead of a direct url visit.
},
showProgress: false,
});
// it also supports events in case you want to do something once scroll ends...
mc.addEvent("complete", function(direction) {
console.log("hello from events, we just finished moving all the way to the " + direction);
});
},
beforeunload: function() {
mc.stop();
mc.options.targetElement.empty();
} // end domready
});
All you need to do is include your mootools more and moootools core, then imageScr00ler.js. Change as you deem fit, use as you like – any linkback or such can’t hurt. Just have a look at the source code and the possible methods and uses on the imageScrOOler example page and use your common sense. I hope somebody does find it useful, any feedback / ideas is always appreciated.
Aaron Newton has written up what appears to be one of the most comprehensive and unbiased answers to the eternal question: jquery or mootools. I cannot recommend it enough to anyone that’s just starting with javascript or is looking at both frameworks from the “which is better for me and my project’s needs” angle. It’s worth mentioning before you begin, this is a comparison of the core functionality, provided by each framework – not what is possible should you decide to build on it.
The short summary: both frameworks are great but serve a different purpose, with jquery is more user and beginner-friendly, focused / optimised around DOM access and mootools, building and extending the javascript native prototypes and methods (not at the expense of the things that jquery can do).
Another way to look at it: mootools takes things further than jquery and makes javascript fun, introduces features that are coming in javascript 1.8 and provides a great layer for object orientated programming whereas jquery is staying where it’s at its best: shortcuts, chaining and styling, leaving anything else you may need to plugins and vanilla javascript.
The comments are also well worth the read, some good points on the pro’s and con’s of each framework and a bit on why mootools does not try to be unobtrusive / conflict free with other frameworks.
Many a post on javascript forums are still on the subject of image pre-loading via vanilla javascript. With so many results on google on a simple pre-loading images via javascript search, it’s surprising how very few scripts do a decent job. To understand why, we need to look at the possible pitfalls here but also to examine when and how image pre-loading can be enhancing the user experience. In other words do you really need it?
There are two scenarios here. Case 1: you just want to load all your images prior to displaying the rest of your page. Whether that’s because you like it this way or you need to get the browser to ‘know’ your images widths and heights first, it does not matter. The arguments for ‘speeding up’ page loads are a bit moot now, with modern connections and modern browsers there are no great benefits to preloading. Either way, you need to arrange your code in a way that allows you to trigger some event or function when the loading is complete in order to continue displaying your site.
And then, there’s case 2: precognitive image loading / cache priming, which is the more interesting use. This is a relatively new trend that involves examining the user’s browsing pattern and anticipating what they do next. For instance, if they are browsing product listings as a result of a search with 100 results (20 per page), it is almost safe to assume they may want to go to page 2 or 3. It is also safe to assume the average user would take a while to finish appraising their results, scroll down and locate the ‘next’ link. This idle slot is where you can put their connection to better use by priming the browser cache with the product thumbnails of the next results page. In this instance, you don’t really care for any onload / oncomplete events, the benefits of the cache will be reaped on the next page instead.
Now, we’ve established why you may want to preload images, let’s focus on the how instead.
There are some considerations we need to be aware of here:
Now, 2 of these are more important than the rest. First of all, it’s important to understand that you need to assign the onload event BEFORE you set the src property of the image object:
// wrong:
var image = new Image();
image.src = 'image.jpg';
image.onload = function() { // evil, won't work if image already cached, it won't trigger
...
};
// right:
var image = new Image();
image.onload = function() { // always fires the event.
...
};
image.src = 'image.jpg';
And second, in Internet Explorer, the onload event fires ALL THE TIME for animated gifs. That’s right, on each loop it fires an ‘onload’ for you. Which is why you need to make sure you release your image objects – or should you need to store them as objects into a new array – remove all onload-based events attached to them.
Anyway, without further ado, the code. I hope it makes sense – you can see it working here.
// assign images as global
var imagesArray = [
"8-0.gif",
"article-bg.gif",
"article-page-bg.gif",
"big-bg.gif"
]; // etc etc, as many image elements as you need to cache.
window.onload = function() {
// local scope. strictly speaking, images loading does not need to wait for onload, so you can change this.
// good to keep it under a namespace / anon closure if you don't use the window.onload.
var loadedImages = [], reportProgress = function(where) {
// used to show how many images loaded thus far and / or trigger some event you can use when done.
// optional to show onscreen..., 'where' should be an object referencing an element in the DOM
// to do it silently, just remove the output bits below.
var output = "loaded ";
output += loadedImages.length;
output += " of ";
output += imagesArray.length;
output += " images.";
where.innerHTML = output;
// this bit will fire when all images done:
if (imagesArray.length == loadedImages.length) {
// total images onComplete. done. rewrite as you deem fit - call your main site load function from here
// keep in mind that if 1 of your images is a 404, this function may not fire, you
// may want to assign onerror and onabort events
// you can loop through them (if you use the objects, then output loadedImages[x].src or inject them.
for (x in loadedImages) {
where.innerHTML += "" + loadedImages[x]; // comment this out - debug.
}
}
}, loadImage = function(imageSrc, reportDiv) {
// actual function that loads image into DOM
var image = new Image(); // local scope, new object created per instance.
image.onload = function() {
if (!image) return;
loadedImages.push(image.src); // record this image path as loaded in global scope
// or... store the objects themselves so you can inject them:
// loadedImages.push(this);
// sample report of progress
reportProgress(reportDiv, image.src);
// remove event and self to prevent IE on animated gif loops and clear up garbage.
image = image.onload = image.onabort = image.onerror = null;
};
image.src = imageSrc;
}, total = imagesArray.length, loadedProgress = document.getElementById("mydiv"); // more local variables
// loop through the images and load.
while(total-- || loadedImages.length == imagesArray.length) {
loadImage("http://fragged.org/images/" + imagesArray[total], loadedProgress, total);
}
}; // end window.onload
I really do hope this helps somebody.
