Tim.Tripcony@lotus911.com
Blog Tags
|
All entries tagged with
javascript
Tim TripconyTim.Tripcony@lotus911.com
 I was booking some travel recently and couldn't select a date on one of the travel sites because they were using window.open, so my browser blocked it as a popup. They weren't trying to sell me anything I wasn't planning on buying anyway, they weren't trying to install malware, it was just a date picker. But I couldn't use it without modifying my browser's security settings (or switching to a less secure browser). It's 2008... window.open? Seriously?
So, for any of you who still use window.open to display a date picker, or a comment form (see Andrew's blog as an example of the right way to do this), or... well, anything else... and the only reason is because you asked someone for an alternative and were simply told, "duh, use a positioned div" - but not told how - hopefully this post will show you how easy a better alternative can be.
To display something that looks like a popup but really isn't, all you really need is:
- a div that hides until needed and has a higher z-index than the rest of the page
- code to show and hide that div, and position it where you want it to display
What's a z-index? If you use layers in your Notes client development, you're already familiar with this concept: think of your user interface as existing in three-dimensional space. The x axis is horizontal, the y axis is vertical, and the z axis measures the conceptual distance between the "front" and the "back" of what's available to the user. Unlike x and y, however, which are typically measured in pixels or some other unit associated with the available width of the user's screen, the z index is theoretically limitless, and is simply identified by an integer. So on a web page (or a Notes layer), anything with a higher z-index is "closer" to the user; anything with a lower z-index is "further" away, and therefore displays "behind" the higher elements. Mozilla.org has a great tutorial on this concept if you want to dig deeper, but for the moment, just remember that the element with the highest z-index displays on top of everything else. Here is an example (also available for download) of using a "positioned div" to display additional content that you might otherwise launch in a separate window with window.open. To enable this, start out by creating a div somewhere in your page markup, give it an id and a class (in my example, I'm using "pseudoWindow" as the id and "layerwindow" as the class), and define some CSS for that class:
div.layerwindow {
background-color: #eeeeee;
border: 3px solid #abcdef;
display: none;
overflow: scroll;
padding: 3px;
position: absolute;
z-index: 2;
}
This causes that div to hide initially, as well as defining how it will look when it's no longer hidden. Next, you'll need some JavaScript code for showing the div, positioning it, and hiding it again:
var LayerWindow = function(){
var getViewPort = function(){
var viewPortWidth;
var viewPortHeight;
var vYscroll;
if (window.innerWidth) {
viewPortWidth = window.innerWidth;
viewPortHeight = window.innerHeight;
vYscroll = window.pageYOffset;
} else if (document.documentElement && document.documentElement.clientWidth) {
viewPortWidth = document.documentElement.clientWidth;
viewPortHeight = document.documentElement.clientHeight;
vYscroll = document.documentElement.scrollTop;
} else {
var bodyTag = document.getElementsByTagName('body')[0];
viewPortWidth = bodyTag.clientWidth;
viewPortHeight = bodyTag.clientHeight;
vYscroll = document.body.scrollTop;
}
return {
w: viewPortWidth,
h: viewPortHeight,
yScroll: vYscroll
};
};
return {
open: function(id, options){
var vp = getViewPort();
if (document.getElementById(id)) {
overlayer = document.getElementById(id);
overlayer.style.width = options.w + 'px';
overlayer.style.height = options.h + 'px';
overlayer.style.top = (vp.yScroll + parseInt(vp.h / 2, 10) - parseInt(options.h / 2, 10)) + 'px';
overlayer.style.left = (parseInt(vp.w / 2, 10) - parseInt(options.w / 2, 10)) + 'px';
overlayer.style.display = 'block';
}
return false;
},
close: function(id){
document.getElementById(id).style.display = 'none';
}
};
}();
Finally, update whatever would be triggering the window.open to instead just display the hidden div:
<a href="#" onclick="return LayerWindow.open('pseudoWindow', {'w':300, 'h':250});">Open layer window</a>
There are a multitude of ways to add further elegance and functionality to this (and nearly every widely used JavaScript framework has their own implementation) - for example, loading the content of the hidden div via AJAX prior to displaying it instead of using pre-populated content - but hopefully this will give you a head start toward eliminating your own use (if any) of window.open... please, think of the kittens.
Tim TripconyTim.Tripcony@lotus911.com
Back when I was experimenting with XIDED, I wrote a utility database to mitigate my primary annoyances when dealing with JavaScript - in Domino in particular, but also a few general pet peeves (you'll probably notice that the recently released beta of 8.5 addresses the first of these):
- The JavaScript editor in Domino Designer is an IDE pretending to be Windows Notepad, failing in that imitation only when it occasionally maintains the current indentation from one line to the next.
- As the complexity of a web application increases, so does the hassle of maintaining all of its application-specific JavaScript in a single source file... the ink was starting to rub off on my Ctrl and F keys.
- Conversely, if you split out your source into a bunch of smaller, more maintainable files, it's a pain to merge them all back into one, so the temptation is to just throw a script tag in for each one, which tends to negatively impact page load times (even if the browser is pulling each from the cache, it still has to check each one separately to see if it's in the cache, so it might not be downloading each again, but there's still a performance hit). But then you still have to refresh the file resource for each that has been updated.
- At one point, the combined uncompressed size of all of my source (including the frameworks I was using in addition to my application-specific code) was just over 1.5 MB, which is ridiculous. But minification and compression added two additional steps to my "build" process.
So out of pure old-fashioned laziness, I wrote what I now call "JSFactory": once I've defined a project version document (to allow multiple versions to be maintained in different directories), listing the location of the source files in the order that they should be combined, an output location for the combined file (and - optionally - compressed, and/or gzipped... since I've configured my server to deliver gzipped content), and a file resource element to update, I can refresh that element with a single click. So I can maintain lots of little source files, doing my coding in Aptana, and then update my application without even opening Designer. It works in Windows and Linux (and presumably Mac, though I don't have one to verify that). So if I've had this for years, why am I just mentioning it now? Well, two reasons. The first is that Chris Toohey's SOTU Sidebar Widget Demo inspired me to add a similar widget to JSFactory, which I did yesterday:  The second is that I decided to try an experiment: in a singular (and possibly only) departure from my traditional "give everything away" approach, I'm offering this for sale. As its usefulness is restricted to a very specific niche task, and future versions of Domino may make it entirely obsolete (here's hoping, anyway), I'm only charging $9.99, and I didn't bother putting in a bunch of licensing restrictions; if you buy it, it's yours to use as you see fit: donate it to your whole team (assuming you have one), put it on as many workstations or servers as you wish, modify the source (yes, I left it open), etc. I realize this means that one person could buy it and just send it around to everyone else, but I'm not looking to "make my millions" with this... I've got a dream job. I just request that if you receive a copy without having purchased it and find it useful, consider buying your own license... it's the same price as most albums on iTunes.
Tim TripconyTim.Tripcony@lotus911.com
Julian's post about JavaScript stack traces reminded me of something I wrote late last year and had been meaning to mention but never did.
Web applications have steadily become more interactive over the last couple of years, and have been evolving from a collection of pages to a sequence of interactions and events. On the one hand, this can be very positive for the user, as we're no longer forced to trigger an entire page refresh for every mouse click. On the other hand, one challenge this presents is that many users are still in the habit of conceptualizing site navigation and interaction in a context of page history; in other words, they expect to be able to click something (i.e. a button or a link), examine the result, then click the Back button and see what they saw before... and click Forward to return. This was already a problem before Ajax when POST requests were involved, but adding Ajax to the equation can compound this even more: by default, not only will clicking Back not show the user a previous state of the current page, in a "one-page application", it'll actually exit the application, possibly even your entire site.
So how can we get around this? Ironically, most workarounds I've seen (including the one that I implemented and am about to describe) make use of the HTML element that was often used to provide Ajaxy behavior before what we now consider to be "true" Ajax gained widespread use: namely, the iframe. When an iframe's location changes, an entry is added to the browser's history (in some browsers... more on that later), even though the location of the page containing it has not changed. As a result, clicking the Back button will simply return the iframe to its previous location without modifying the container's location. Similarly, once that's occurred, the history contains an entry in the forward direction, so clicking Forward at that point will again navigate only the iframe, still leaving the container location intact.
How does that help us? Chances are, those familiar with JavaScript's Function.apply() have already guessed where I'm headed with this. As I commented on Julian's post, a handle on a function can be passed as a parameter to another function. This is used all the time in Ajax requests to specify a callback function: once the request has been processed, the specified callback function is executed to respond to the result of the request. In this case, however, we're not associating a function with a request for remote data (or submission of data); instead, we're actually associating a function (and the parameters that should be passed to it) with navigation. Here's how it works:
- Instead of calling the function directly, we pass a handle on the function (along with an array of parameters to call it with and an optional scope) to another function - AjaxHistoryManager.register(). For example:
function sayHello (sender, recipient) { this.innerHTML = recipient + ', ' + sender + ' says hello.'; }
AjaxHistoryManager.register(sayHello, ['Me', 'World'], document.getElementById('helloDiv'));
NOTE: the lack of parentheses after the reference to sayHello is intentional; we're not calling the function at this point, just passing it as an argument.
- The register() function creates an object to store the function handle, parameter array and scope object (which defaults to the passed function if no scope is specified), pushes that object to an array that stores all of the function calls that have been registered since the container page was loaded, and increments a counter.
- Finally, register() sets the source of a hidden iframe to the URL of a Page design element (assuming you're using Domino; a very minor tweak to this would allow it to behave identically in PHP, ASP, JSP... pretty much anything), including a query string parameter indicating the current counter value.
- The Page loaded in the iframe has only one job: it includes a script tag that (using computed text) passes the counter value to window.parent.AjaxHistoryManager.execute(); this function retrieves the object stored earlier and calls the associated function with the stored parameters, binding "this" to the correct scope object. The reason I almost never use "this" in JavaScript is that any number of factors can cause a function to lose a handle on the scope you originally intended it to have, which will cause any references to "this" to apply to the new scope. That's not a problem in this case, because we're calling .apply() on the function to be run, which allows us to explicitly specify a scope object. So, in the example above, "this" refers to the HTML element that was passed as the scope object. If the function you're registering doesn't have any references to "this", you can leave off the scope parameter entirely and just pass the function handle and a parameter array.
The result is that the registered function is still called almost immediately (depending on how long it takes your server to send the 94 byte overhead for the iframe Page), but the browser history now contains an entry associated solely with that event. Ergo, executing a series of events in this manner allows the user to execute them again (with the same parameters and scope each time) simply by clicking Back and Forward. You can see an example of this behavior here (the sample database is also available for download). On that page, click the "Increment Counter" button a few times, then click Back and Forward (Alt+Left / Alt+Right also work)... the displayed counter will increment and decrement based entirely on those navigation events. This works correctly in Firefox and I.E., but not Safari or Opera. In Opera, navigation does appear to update the iframe, but the stored function is not called; in Safari, clicking Back actually navigates the entire container page. In both cases, though, the function is still executed initially upon registration; in other words, your application will still work, but will not have the benefit of triggering previously executed functions again via navigation events. I still have never had to support either of these browsers within an enterprise context, but if anyone has ideas on how to extend this approach to fully support either or both, let me know. One last disclaimer: this approach is best suited for "read-only" operations. For example, user interaction causes some change to a portion of a page (i.e. resorting data), and we want reverse navigation to "undo" that change. This approach gets a whole lot messier if a POST is involved: if the methods being executed are actually updating data in the database, then executing them in reverse order needs to revert the database content to its previous state - whether by resetting field values on one or more documents, or actually removing documents that were added by the executed method(s).
|
|
