With nice javascript toolkits out there like dojo, scriptaculous, and YUI there's mind bottling boggling stuff out there that you can do. One of the newest, neat things I've found was a javascript image cropper built off of scriptaculous. A working demo for it can be found here. Credit for pointing me in the direction of this link goes to Thom Wetzel and his post at Shacknews (a non-work related gaming site) who's using it with his gamewith.us community gaming site.

Since most of my duties revolve around the PHP/database solutions I've rarely had to do much integration with Flash (despite our company's strong ties to it). A recent project had me dabbling into the realm of some of my coworkers so I'd figure I'd throw some pointers out there for us backend dev guys. Normally when embedding flash objects we use the swfobject script from Geoff Stearns to handle flash installation and version checking. One of the problems when combining DHTML (especially DHTML menus) and flash is the problem with flash appearing over your DHTML layers no matter what z-index values you assign them. The quick fix for that is to set the wmode parameter for your flash object to "transparent." Using the swfobject you would just call the addParam("wmode", "transparent"); member function of your instantiated swfobject.

Another small thing to watch out for is when using the ExternalInterface with flash to expose functions within flash to javascript you'll need to use the id you specify when you instantiate the swfobject, not the id for the div that the object writes to. For example if you were trying to access an exposed function named "setAudio" for an swf created with the following code:

<script type="text/javascript">

<!--

var so = new SWFObject("flash/myflash.swf", "flashPlayer", "895", "263", "8", "#ffffff");

so.addVariable("menu", "false"); so.addParam("wmode", "transparent");

so.addParam("allowScriptAccess", "always"); so.write("mainFlash");

//-->

</script>

Your javascript would be accessing "flashPlayer," not "mainFlash."

Occasionally certain usability suggestions seem to make sense until you actually see them in person. For one app that we recently worked on we relied heavily on the Dojo toolkit and the dialog widget which creates a modal, centered dialog layer. One suggestion we received was to not have the dialog centered, but to have it appear at the current position of the cursor. As a result, I created the MoveableDialog widget which extends the normal Dojo dialog. Although we didn't end up using this technique, it may be helpful in other instances and it also provides a good starting point for trying to extend the Dojo dialog widget.

You can grab the MoveableDialog.js and place it in your dojo/src/widgets directory then you can call it similarly to the normal Dialog (of course you would specify MoveableDialog in your dojo.require statement and in the div where you specify the dojoType). The main difference is the show function now accepts two parameters for the coordinates of the left and top position of where to place the dialog. If you combine it with this mousetracking script you can have the dialog appear at the cursor position.