ClipStation is designed to be lightweight, flexible, and easy to implement. What makes ClipStation different from other clipboard SWF solutions is the ability to decode HTML character entities, allowing you to pass complex HTML markup to the clipboard from within form elements, divs, pre tags, etc. We developed ClipStation for use on a widget sharing page we've implemented for a client. After looking around for a good lightweight cross-browser solution and coming up empty handed, we decided to build our own. We're now happy to offer it to you at the low, low price of free.

Version 2.0 includes changes to allow access to the clipboard in Flash Player 10. Adobe changed the security requirements for clipboard access in version 10 of the player; now a user action is required before a SWF may access the clipboard. Instead of using a single hidden instance of the ClipStation SWF, we embed an instance for every clip that the user clicks to perform the clipboard copy. A source distribution is available, so you can change the design to fit your needs.

More information and the release package can be found at thirdpartylabs.com/clipstation/

»Download ClipStation 2.0

"We were looking at SWF Address a while ago. While it’s very cool it was useless for what we wanted. By using HTML anchors (# in the URL) the deep links are only relevant to client side logic inside the browser (JavaScript, HTML and Flash).

If you serve HTML content generated server side, in addition to flash there is no way to extract the deep link from the URL (after the #) as it’s not passed to the server in the request!

I will be interested to see if they have updated this in the new version… and also see what changes have been made to SWFObject2, or swffix or whatever it’s called these days."

I had to read that twice.

SWFAddress is not a solution for implementing multiple content types. It's purpose in life is to keep the browser informed about the user's movements within a rich application. It does that job very well. One of the things you can do with SWFAddress is implement your own solution for managing your URLs across multiple content types.

Jon and I are just finishing up a big client site for which we have a nifty flash client and an SEO/Usability optimized HTML version of all content on the site. SWFAddress allowed us to maintain a similar URI structure for both, and a little bit of custom javascript handles the translation of SWFAddress URIs, which all start with # to the standard URIs, and vice-versa. SWFObject handles the embedding of the Flash client. It's a really simple solution that took less than an afternoon to prototype and refine into a production-ready solution. I'm not saying this to make myself out to be a bad-ass, it's just not rocket science. All it takes is a general understanding of how the tools work, and the willingness to craft your own solutions to your specific problems.

There are well built, elegant, open source libraries to do just about anything these days. The thing is, they're libraries, tools, not complete solutions. They will solve the tough 80% of your problem for you. It's up to you to do the last 20% and make the tool work for you. Enter the 80/20 rule, or, more specifically, the 2080 concept.

The 20 missing percent of functionality will take up 80% of the build time.

If you expect canned solutions to solve your problems 100%, you will constantly be disappointed, and, most likely, be building poor software. If you go into your project knowing that a tool you will rely on provides a limited set of functionality, and you will need to do devote time and energy to make it fit, you will be more likely to succeed.

"There is something to be learned from a rainstorm. When meeting with a sudden shower, you try not to get wet and run quickly along the road. But doing such things as passing under the eaves of houses, you still get wet. When you are resolved from the beginning, you will not be perplexed, though you still get the same soaking. This understanding extends to everything."

-Yamamoto Tsunemoto, Hagakure