Phing is a PHP build process that uses XML , ANT style syntax.

At some point in development, the choice is made to begin professional work. If more than 1 developer contributes to the effort, then an the easy mode of keeping in sync with that person and, in the future, others that may join the effort is required. Because not all developers are alike, and not all hosting providers are alike, you must have a solid build process of your code.  The build process automates the routines that every developer must do, either daily, hourly, or with every code change as well as when code is pushed into client facing distributions.  Phing is an XML to PHP build process that imitates the ANT build process that many development shops are used to.  As a PHP developer, Phing is much easier for me to work with and get things done, as well as keeps things simple when needing to update the build process.

Installing Phing

Dependencies :

Straight from the source, “To use Phing you must have installed PHP version 5.2 or above compiled –with-libxml2, as well as –with-xsl if you want to make use of advanced functionality.” I would hope that if you are doing any serious PHP development, you would already meet these requirements.  If you are needing to upgrade your PHP, then you really should reconsider what you are using PHP for.

My approach to installing Phing is the simplest solution and it follows exactly what the setup guide describes by using Pear.

$ pear channel-discover pear.phing.info</span>
$ pear install phing/phing

You should now be able to test Phing by simply typing ‘phing’ from the command line. You should get an error similar to this: ‘Buildfile: build.xml does not exist!’

Copying and Moving Files

One of the most important parts of a build process is the ability to move and copy files to different places. Phing makes this easy and allows you to modify the files as you are moving them. Different reasons to have a build process will determine how you would like to set up your folder paths for Phing to manipulate. Let’s do one that is pretty powerful and pretty simple at the same time: copying all files from a folder, into a single file, located in an entirely different folder.

build.xml

<?xml version="1.0" encoding="UTF-8"?>
<project name="MyWebapp" default="default" basedir=".">
<target name="default">
 <foreach param="dirname" absparam="absname" target="compile-folder-js">
  <fileset dir="./js">
   <type type="dir" />
   <depth max="0" min="0" />
  </fileset>
 </foreach>
</target>
<target name="compile-folder-js">
  <mkdir dir="./${dirname}-js" />
  <fileset id="filestocompile" dir="js/${dirname}">
   <include name="**/*.js" />
  </fileset>
  <append destFile="./${dirname}-js/${dirname}.js">
   <fileset refid="filestocompile" />
  </append>
</target>

Phing works using a Build.xml file to run the commands when Phing is called. The only requirements of this file are the project tag and a default target. We have set our default target to run code that dives into the ./js folder path; loops through every folder in this path and passes them to another target (compile-folder-js) for processing; one at a time. Now we can have in our source ./js/jquery/ and ./js/modernizr/ and this will take all JavaScript files send them to the compile-folder-js target.

The compile-folder-js target will loop through the directory that is passed to it and grab all JavaScript files (recursive folder depth because of the **/ ) and append them to a single file under the path ./directory-js/directory.js. This is pretty great when it comes to a production versus a development site. For instance, in a development site, you may have 5 different JavaScript files, but in a Production site, after a build, you could have a single JavaScript file. However, one point to be aware of, the files will be appended in teh order the file system sends them (defaults as alphabetical order).

Sanitizing Files

Now that we are concatenating our JS files, we can take it further and do some sanitizing with JSLint. Adding this to our current project is fairly simple. Start by downloading the most recent version of JSLint for your operating system. Make sure to uncompress the file and remember where you put the uncompressed file.

<?xml version="1.0" encoding="UTF-8"?>
<project name="MyWebapp" default="default" basedir=".">
<target name="default">

 <property name="jslint" value="./path/to/jslint/jsl-0.3.0-mac/jsl" />
 <echo msg="Checking JS for errors..." />
 <jsllint haltonfailure="true" cachefile="./jslint.cache" executable="${jslint}" conffile="./path/to/jslint/jsl.default.conf">
  <fileset dir="./js">
   <include name="**/*.js"/>
  </fileset>
 </jsllint>

 <foreach param="dirname" absparam="absname" target="compile-folder-js">
  <fileset dir="./js">
   <type type="dir" />
   <depth max="0" min="0" />
  </fileset>
 </foreach>
</target>
<target name="compile-folder-js">
  <mkdir dir="./${dirname}-js" />
  <fileset id="filestocompile" dir="js/${dirname}">
   <include name="**/*.js" />
  </fileset>
  <append destFile="./${dirname}-js/${dirname}.js">
   <fileset refid="filestocompile" />
  </append>
</target>

We’ve added a JSLint check that runs through all of the JavaScript files and send them through the JSLint downloaded binary for checking. The process will now stop if you right improper JavaScript, immediately letting you know if you have issues with your code.

Compressing Files

Sometimes, checking your JavaScript for errors, and moving into a single folder is just not enough. You still may want to compress them down, obfuscate them, so that they are at the absolute smallest size possible. For this, a good option is Google Closure Compiler. You can get a good task to help with this so that it’s a drop in solution. Just drop this new task definition into your phing path and you are set. Now our code can implement this piece to get a better JavaScript file.

<?xml version="1.0" encoding="UTF-8"?>
<project name="MyWebapp" default="default" basedir=".">
 <taskdef name="googleclosurecompiler" classname="phing.customtasks.GoogleClosureCompiler" />

<target name="default">
 <property name="jslint" value="./path/to/jslint/jsl-0.3.0-mac/jsl" />
 <echo msg="Checking JS for errors..." />
 <jsllint haltonfailure="true" cachefile="./jslint.cache" executable="${jslint}" conffile="./path/to/jslint/jsl.default.conf">
  <fileset dir="./js">
   <include name="**/*.js"/>
  </fileset>
 </jsllint>

 <foreach param="dirname" absparam="absname" target="compile-folder-js">
  <fileset dir="./js">
   <type type="dir" />
   <depth max="0" min="0" />
  </fileset>
 </foreach>
</target>
<target name="compile-folder-js">
  <mkdir dir="./${dirname}-js" />
  <fileset id="filestocompile" dir="js/${dirname}">
   <include name="**/*.js" />
  </fileset>
  <append destFile="./${dirname}-js/${dirname}.js">
   <fileset refid="filestocompile" />
  </append>

 <googleclosurecompiler compilationLevel="SIMPLE_OPTIMIZATIONS" targetDir="./${dirname}-js/" failOnError="true" outputFile="${dirname}-compressed.js" merge="true">
  <fileset dir="./${dirname}-js/}">
   <include name="${dirname}.js" />
  </fileset>
 </googleclosurecompiler>
</target>

Conclusion

We’ve been able to now create a worthwhile setup that allows a webapp to move,verify and compress all of its JavaScript files whenever the command ‘phing’ is ran on the path. This is a very simple setup, but one that can really be expanded on. For instance, you can use dates or hashes appended to files so that caching is easier. You can setup a multi-directory structure for better handling of JS versions. You can even pre-gzip your code so that it is much faster for downloads and lighter weight on the server-side load.

Hopefully this will get you into the process of using Phing and developing a solid build process in your web coding.

Update – 4/6

Another nice approach is found in the comments, take a look!

It starts with how search engines manage what URLs your site is using. Search engines need to keep a good idea if you are trying to manipulate your results on the search by including ‘junk’ content. A familiar approach is to have two URLs point to the same content. This way, you are using the same content multiple times and would expect to have a better result on the search engines (because you have so much content on the subject!). Search engines have caught on to this (Google suggestions), and they keep a signature of all the content for your pages with the URLs; if they detect the same or very similar content across different URLs they instinctively rule that content out of the equation (SEO by the sea).
Codeigniter is actually suggesting you make two URLs for the same content with their recommended solution by adding the following code into a .htaccess file at the root of your codeigniter installation.

RewriteEngine on
RewriteCond $1 !^(index.php|images|robots.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]

Line by line, this is stating to ‘rewrite’ everything that isn’t beginning with index.php in the URL so that it does not contain index.php on the server-side logic (hidden from the user). However, if the user were to use the URL with index.php still in it, guess what; it will still work. You now have two URLs pointing to the same content!
The SEO friendly way to do this would require a little bit of ‘tom foolery’ with the code. Here is my .htaccess file that I use for my codeigniter sites.

Options +FollowSymLinks
DirectoryIndex index.php

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /

    RewriteRule ^index.php?(.*)$ $1 [L,R=301]

    RewriteCond $1 !^(home.php|css|js|images|robots.txt)
    RewriteRule ^(.*)$ /home.php/$1 [L]

<IfModule !mod_rewrite.c>
    # If we don't have mod_rewrite installed, all 404's
    # can be sent to index.php, and everything works as normal.
    # Submitted by: ElliotHaughin

    ErrorDocument 404 /index.php
</IfModule>

First thing you will notice is that I have very similar code involved in my .htaccess that you find in the codeigniter code.

	RewriteCond $1 !^(home.php|css|js|images|robots.txt)
	RewriteRule ^(.*)$ /home.php/$1 [L]

I have changed out the index.php with home.php (which doesn’t exist yet) and I’m also allowing some CSS and JS folders through the ‘rewrite’. Above this code I’m adding the SEO friendly 301 redirect hook.

    RewriteRule ^index.php?(.*)$ $1 [L,R=301]

I am purposely rewriting any URL that begins with index.php to no longer begin with index.php. I also pass [R=301] which tells a browser or search engine that the old URL no longer exists and they need to use the new one from now on.
Back to the home.php; you need to create a new file called home.php and place it in the same place as index.php. The only thing that needs to be inside home.php is the following code.

<?php /*this file is for SEO purposes */
require('index.php');

Now, anything going to home.php will be routed to index.php internally so nothing in codeigniter needs to change.

Conclusion

This hasn’t solved the multiple URLs completely, as now anything pointing to home.php will be a second URL to the same content. However, you should’t have anything pointing to this URL and you can make sure that search engines cannot use this URL by adding a clause to your robots.txt. Anybody using the older index.php URL will get a 301 redirect that lets the software they use know not to use it anymore.

There are probably also options to handle not needing another file (home.php) in the .htaccess file but I was unable to get the same results that I am getting with this method. Feel free to correct or update, or tell me why I’m wrong!

body {
-moz-box-shadow: inset 0 0 8px rgba(0,0,0, 0.25);
-webkit-box-shadow: inset 0 0 8px rgba(0,0,0, 0.25);
}

This code actually workedworks, and I didn’t notice any issues. However, the 8px fade was too abrupt; I kicked it up ‘just a tad’ to 200px (I have large ‘tads’). Big mistake as all ‘advanced’ browsers were crumbling in my wake. If they support box-shadow, they failed. The page loaded, but scrolling was a complete and utter failure.

For now, I will have to avoid doing this, especially to the large <body> tag. I will chime back in on the topic once I get some solid evidence and facts about it.

Logging In

The new Digg can be viewed by going to http://new.digg.com which drops you into a pretty nice looking log in screen.

Connecting

The first time you log in, it has a really easy to follow setup that asks some basic questions for you to connect to other social sites. I connected them all; Twitter,Google and Facebook.

Apparently not a single friend of mine is currently using Digg V4, no surprise there!

Usage

Digg is setting itself up in a very good way. They are re-inventing themselves with this idea. Before, you could only get Diggs via categories like Top Ten, Technology, etc. or you could find users and view the Diggs that they Dugg. But now, it is being setup so that you control your Digg feed, according to those users that you Digg. In which you can then Digg items up. So from now on Digg will be able to suggest to you, only the items that you really would like to see (mrbabyman all the way!).

Bugs

I did however encounter a bug, to which I filed a report. If you try to load more items than there are currently in the system, you get an error stating that there are no more items, but the loading never quits and still shows up as a click-able link. So there are still some kinks to work out, but I for one think this is a great way to stay ahead of the rest!

– Update –

Another bug was discovered. When clicking to add a link to your account (like adding my website to mine), if you press after typing in your web address, the form does not submit. Instead the page refreshes and you lose your previous entry you typed in. The only way to submit the form it to actually click the button.

Let’s take a look at the core issue. Here is what a typical dialog looks like in jQueryUI 1.8.2 with some nice buttons.

Perfect example of a jQueryUI Dialog

Here’s the simple code for this.

<article id="dialogs">
	<a href="javascript: void(null);" id="dialogbutton">Open Dialog</a>
	<div title="this is my test this is my test this is my test this is my test" id="dialogtest">
	This is a div dialog test. This is a div dialog test. This is a div dialog test. This is a div dialog test. This is a div dialog test.
	</div>
</article>

<script type="text/javascript">
	$(document).ready(function() {
		/* Create a dialog */
		$("#dialogtest").dialog({
                        title: "Alert!",
			modal: true,
			buttons: {
				"Ok": function() {
					$(this).dialog("close");
				},
				"Cancel": function() {
					$(this).dialog("close");
				}
			}
		});

		/* Add Dialog Button Functionality */
		$('#dialogbutton').click(function(){
			$('#dialogtest').dialog('open');
			return false;
		});
	});

</script>

That’s really great, I mean that code is so small and yet you can get such a great looking item out of it. So how can I have a problem with that? Well let me tell you how the buttons are made, you have a name and then you have that name point to a function. The name is the text of the button, the function is the action of the button. And that’s it. Period.

Now, I find it great that I can use these simplistic featuresets and get ‘get by’ but normally my “Cancel don’t ever touch me button” is the color red(ish) while my “Oh you need to hit me to move on” button is the color green(ish). But you cannot do that (easily) with this current setup. In fact it’s very sloppy to force this setup into doing that and it ends up using a great amount of code just to do one thing, add a class.

To solve this, I did what any self respecting JavaScript ninja would do, I said goodbye to jQuery UI I opened up the source code and took a peek, found out where I could attack (fix) the code and I did it.
So before I show you the code, I will show you how I decided buttons should/could be made. My process is 100% backward compatible, yet more difficult and easier to mess up (the original goal of jQueryUI was obviously to make it as simple as possible).

Buttons with my code changes can now be made like this

buttons: {
	"Ok":  function() {
		$(this).dialog("close");
	},
	"Cancel": {
		action : function() {
			$(this).dialog("close");
		},
		type : "cancel"
	}

/* This is poor CSS by design to be simple and readable */
 div.ui-dialog-buttonpane button.cancel { background:none; border:0px none;color:red; }

and the old way of doing it will still work just fine as well.

I’ve gone ahead and added a few features, namely it is now name-points-to-object instead of the old name-points-to-function mentality. This object has two attributes: action and type. Action is the old function() that was pointed to and it will be called when this button is clicked. Type is the new feature on the block, it’s just a CSS class that is added to the function using jQuery.addClass. I’ve tried to keep is simple, and at the same time, make it robust and backward compatible. Here’s a simple change that is possible using this feature.

Now my dialogs can look like this when I want them to. This is a big usability thing (make the buttons descriptive, not just in text but in color/design and function).

So the secret sauce to all of this is actually an extension of the jQueryUI 1.8.2 Dialog code (more like rewrite of some of the code). This code can only be ran AFTER jQueryUI 1.8.2 has been created, otherwise you will get an error. I placed this code into the jQueryUI 1.8.2 custom.js file itself for easy keeping; just drop it at the bottom of the file.

/* TorchUI dialog button fix */
(function($) {
	var _createButtons = $.ui.dialog.prototype._createButtons;
	$.ui.dialog.prototype._createButtons = function(buttons) {
		var self = this,
		hasButtons = false,
		uiDialogButtonPane = $('<div></div>')
			.addClass(
				'ui-dialog-buttonpane ' +
				'ui-widget-content ' +
				'ui-helper-clearfix'
			);
		// if we already have a button pane, remove it
		self.uiDialog.find('.ui-dialog-buttonpane').remove();

		if (typeof buttons === 'object' && buttons !== null) {
			$.each(buttons, function() {
				return !(hasButtons = true);
			});
		}
		if (hasButtons) {
			$.each(buttons, function(name, fn) {
                        /* Begin the code change here */
			// Check to see if fn is being passed in as a funciton, assume it's an object if not.
			 	if(!$.isFunction(fn)) {
			 		var buttonclass=fn.type;var func=fn.action; }
			 	else {
			 		var func=fn; var buttonclass=""; }
				var button = $('<button type="button"></button>')
					.text(name)
				/* Add a class to the button, if there is a class */
					.addClass(buttonclass)
					.click(function() { func.apply(self.element[0], arguments); })
					.appendTo(uiDialogButtonPane);
				if ($.fn.button) {
					button.button();
				}
			});
			uiDialogButtonPane.appendTo(self.uiDialog);
		}
	}
})(jQuery);

If you have questions, please respond, I promise not to take them personally

So recently I discovered a very nasty bug dealing with jQuery UI dialog (withe modal:true) widgets that seems to only occur in Internet Explorer. It goes like this: If you are using a dialog with a screen reader, your main mode of navigation is with the keyboard. This is typically driven via the focus on elements. In jQuery, focus is demanded on the dialog because of the modal command. You are unable to focus on anything other than the dialog and it’s elements. Here’s the issue however, jQuery successfully can keep focus on the dialog in all browsers tested (FF, Safari, Chrome) so that the focus cannot leave the dialog. However in Internet Explorer (6, 7 and 8 ) your focus can get to the address bar, simply by tabbing to it. Once in the address bar, jQuery is no longer able to track and handle the focus, so inevitable, after tabbing through the menu, focus come back to the window. But instead of going to the dialog, it goes to the first element that can be tabbed to, which is undoubtedly BEHIND the modal dialog. jQuery, subsequently locks the tabbing at this point, most likely because you have focus on and element that is unable to be focused (in jQuery’s dialog algorithm).

So I cannot have this as that would literally cut 75% of my users from being able to use just a keyboard with the sites I’m maintaining. So I had to find a solution. First, IE seems to be the only browser with this issue and it has something to do with the fact that the focus moves out of the DOM’s control (out of jQuery’s control). But the focus would always at least get back to the first element that could be tabbed to, and then lock. So I devised a plan. What if the first element, when focused, looks for an open dialog and if it is there, focuses on that dialog? So I tried it out, like this.

$(document).ready(function() {
    $(":tabbable:first").focus(function() {
           $(".ui-dialog:visible:last :tabbable:first").focus();
    })
});

Amazingly enough, this is the exact solution to the issue. This is how it reads.

1. On page load
2. Get the first element that can be tabbed to in the body
3. When this element gains focus, check for a visible dialog
4. Take the visible dialog that is last (the last one drawn in the html) and get the first element that can be tabbed in it
5. give focus to that first element.

Now, in IE, when focus returns to the document, it goes to the dialog box, specifically, the close icon on the dialog box, thereby not breaking the fact that there a modal open on the page.

Now, there are some issues with this.  For one, the code is just assuming that the last dialog in the html that is visible is the one that is to be focused on.  Quite frankly, that’s what I need it for, as I try not to overlay dialogs, and when it do, the newest one is normally always on top.  However, there are times where you may swap between two dialogs, and the one that is on top is not the last dialog in the html, you would still have this issue in this case.  But for probably the other 95% of the cases, this is a clean and easy way to ‘fix’ the accessibility issue in IE with jQuery UI dialog modals.

This ‘root’ is strictly for developers. It’s not going to give you any ability to do anything to your phone yet, unless you really know your *nix commands well enough not to screw something up on your phone. So continue only if you really want this ability (the ability to really screw up your phone).

You can follow the direct postings here.
I’ve downloaded the file (best link is here). You should also download this file, as it will be needed.

md5sum of the boot partition:
3e49d99b320cf5c20bedf09343c1155c /dev/mtd/mtd2

Here is the `how-to` that embeem posted, I will add to it where I see fit, just to help some of those out as to what is going on.

Download the zip file

You can find the link at the top of this post.

Rename to “update.zip” and copy to the sdcard

It is currently named `droid-root.zip`, `update.zip` is required as that will be used internally by the script in the program.

Power off the DROID and power back on while holding the X key
When you see a “/!” symbol, press both vol+ and camera

This isn’t magic, it’s simply a rescue mode. Slide the keyboard out to start. It’s very easy to figure out what is going on here. You have to press and hold the volume Up key then press the camera button.

Use the onscreen menu to install update.zip

You must use your d-pad to do this. just choose update.zip from the menu.

Once installed you will be able to run “su” from your adb shell.

This one is the kicker, best explained by syntrix

you have to attach your droid in debug mode in eclipse and use adb from the sdk. Again, I’m holding off on this, it’s my only phone.

But once you get this access, you can run commands natively, and copy files to the sd and pull them off the droid.

ADB is only ran from the SDK developers tools. In other words, you are running command from your computer, not the phone.

Now, to take this a step further, we can also get a terminal emulator running on the phone with root access according to mjxg’s post…

1) download this: http://www.magicandroidapps.com/su.zip
2) push it to your phone

C:Android>adb push su /data/local
595 KB/s (76200 bytes in 0.125s)

3) C:Android>adb shell
$ su
# mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
# cd /system/bin
# mv su osu
# cat /data/local/su > su
# chmod 6755 su

4) verify

# ls -l *su
-rwsr-sr-x root root 76200 2008-08-01 05:00 osu
-rwsr-sr-x root root 76200 2009-05-30 11:28 su

5) finish

# sync
# reboot

6) open up a terminal emulator on the phone and run `su` and enjoy

With all this said, this is a remarkable, easy root access. It literally is just adding a file (‘su’) that the user has permissions to. ‘SU’ means, switch user, and by default, that user is root. Giving the user access to this file, means they can run that command, and if that file has the right permissions, which is does in the update, it will run ‘as’ root. And tada, you can now begin to get access to the rest of the system!

Developers will now take over.

I ask myself, “when using a menu, why do I have to drag my mouse from one button to the next, and fear losing the menu if I cross it’s border anywhere?”  Some menus are just annoying because they disappear mid mouse move, some are extremely hard to use because of several layers of menus, some I have resorted to using `tabs` to get to the correct menu item.  It’s unfortunate that people can’t get this right.

I have a simple fix that hopefully sharing it will help others. It’s basically a menu that buffers the time you are hovering, that way if you mistakenly move your mouse into the wrong area, you have a brief period of time to correct yourself.

Start with the HTML code:

<ul id="menu">
	<li class="nav"><a><span>ONE</span></a>
	<ul>
		<li><a><span>one</span></a></li>
		<li><a><span>two</span></a></li>
		<li><a><span>three</span></a></li>
		<li><a><span>four</span></a></li>
	</ul>
	</li>
	<li><a><span>TWO</span></a></li>
	<li class="nav"><a><span>THREE</span></a>
	<ul>
		<li><a><span>one</span></a></li>
		<li><a><span>two</span></a></li>
		<li><a><span>three</span></a></li>
		<li><a><span>four</span></a></li>
	</ul>
	</li>
	<li class="nav"><a><span>FOUR</span></a>
	<ul>
		<li><a><span>one</span></a></li>
		<li><a><span>two</span></a></li>
		<li><a><span>three</span></a></li>
		<li><a><span>four</span></a></li>
	</ul>
	</li>
</ul>

The menu is a simple list within a list. There are essentially only four main list items; ONE, TWO, THREE and FOUR. Each of this list items has their own list of list items generically named one, two, three and four. I personally stick with lists as my menu’s of choice because they degrade gracefully in case of CSS/JavaScript issues.

This list by itself isn’t much, in fact it’s not even a menu. CSS will be needed to really make it work correctly.

#menu li {
	list-style:none;
	float:right; /* Makes IE 6,7,8 act like FF */
	position: relative;}
#menu li a {
	display:block;
	width: 160px;
	height:35px;
	margin-top: 5px;}
#menu li a span{
	padding-left:10px;
	line-height:2.8em;
	color: #000000;
	font-weight:700;}
#menu li a:hover {
	font-weight:bold;}

#menu li ul li a:hover span{ color: #222222; }

	#menu li ul {
		margin:0px;
		position:absolute;
		left: 160px;
		top:-90px;}
	#menu li ul li {
		padding:0px;
		border:0px;
		border-collapse:collapse;
		margin:0px;
		height:34px;}
	#menu li ul li a{ margin:0px;padding:0px;border:0px;}
	#menu li ul li a span{
		display:block;
		padding-top:7px;
		font-weight:100;
		line-height:1em;
		font-size: 83%;}

This is some simple CSS that will make the UL/LI lists to really act like lists. Now the only issue is that you need it to act like a list. So the final piece of code to this puzzle is to add some JavaScript. I am using the jQuery library as my choice for creating this script, so it’s necessary to have that package (1.3+) installed for this to work. You can drop this script into the footer element inside of ‘script’ tags so it will run. It will run automatically on page load.

$(document).ready(function() {
	/* Setup the Menu */
	$("#menu > li > ul").hide();

	$("#menu li.nav").hover(
		/* on mouseover */
		function(e) {
			hoverMenu = this;
			if(this == closingMenu) {
				clearTimeout(closeMenu);
				clearTimeout(openMenu);
				$(this).find("ul:first").show("fast");
			} else {
				var newMenuOpen = function() {
					$(hoverMenu).siblings(".nav").find("ul:first").hide();
					$(hoverMenu).find("ul:first").show("fast");
				}
				openMenu = setTimeout(newMenuOpen, 500);
			}

		},
		/* on mouseout */
		function(e) {
			closingMenu = this;
			var closeMenu = function() {
				$(closingMenu).find("ul:first").fadeOut("fast");
			}
			closeMenu = setTimeout(closeMenu, 500);
		}
	);
});

The final product is quite a nice and simple dynamic menu that adds just the right touch of usability. Now, typically, I would never say that a menu with sub menus popping up everywhere is something of a usability menu system, it’s not. But sometimes, a nice menu like this is needed, especially if there is a lot of information and ‘drill downs’ that need to be accessed quickly. In any case, you can see my demo here. Leave some comments if you have any questions, and enjoy! You can also see a fully implemented version at Xcessorries Squared.

You can jump to the code here, or continue.

I started by writing some simple code that follows the API.

scribd_doc.addParam( 'mode', 'slide' );
scribd_doc.addParam( 'height', 800 );
scribd_doc.addParam( 'width', 600 );
scribd_doc.addParam( 'jsapi_version', 1 );
scribd_doc.addParam( 'auto_size', false );
scribd_doc.write( 'flash_catalog' );

Where ‘flash_catalog’ is the container div of the Scribd PDF.

This however led me to have a height that follows the default rules (width multiplier of 85/110) where the height matches how much space is in the window. So I progressed further with this code.

var oniPaperReady = function(e){
 $("#flash_catalog embed")
.attr("wmode","transparent")
.hide()
.css({"height":"800px", "width":"600px"})
.show();
}

scribd_doc.addEventListener( 'iPaperReady', oniPaperReady );
scribd_doc.addParam( 'mode', 'slide' );
scribd_doc.addParam( 'jsapi_version', 1 );
scribd_doc.addParam( 'auto_size', false );
scribd_doc.write( 'flash_catalog' );

So now I am dropping in a listener in the API to wait for the document to load. I then hide the ‘embed’ flash information, then add the height and width, then re-show the flash element.

You may notice, I’m using jQuery, in which you can do the same thing with regular JavaScript, although quite a bit more complicated (ask if you really really need that code).

An astute reader would also notice one thing, I’m not adjusting for an ‘object’ tag, only the ‘embed’ tag (the difference for flash between different browsers). I figured out this novice mistake while testing in Internet Explorer. Here’s the finished code, that works, removing the nasty height issue.

var scribd_doc = scribd.Document.getDoc( #######, 'key-*******************' );

var oniPaperReady = function(e){
$("#flash_catalog embed")
.attr("wmode","transparent")
.hide()
.css({"height":"800px", "width":"600px"})
.show();

$("#flash_catalog object")
.attr("wmode","transparent")
.hide()
.css({"height":"800px", "width":"600px"})
.show();
}

scribd_doc.addEventListener( 'iPaperReady', oniPaperReady );
scribd_doc.addParam( 'mode', 'slide' );
scribd_doc.addParam( 'jsapi_version', 1 );
scribd_doc.addParam( 'auto_size', false );
scribd_doc.write( 'flash_catalog' );

The final word; I’m adding the transparent mode so that I can then have a menu that drops on top of the flash. This works very well!