Getting tired of all the EVO/Android/iPhone love Jake’s been spewing lately? How about something a bit more dry and developery? As promised in a prior post, here’s a more technical writeup of how I built the WebCenter sharing bookmarklet. I was hesitant to write about this because it’s not like writing a bookmarklet is new and interesting… there are tons of tutorials on the web after all. But as with everything, writing about it will make me appreciate the work I put into it more, I suppose.
There are a few pieces to that make this bookmarklet possible:
- Content iframe originating from the domain you’re sharing to (bookmarklet.html, #3 in the diagram above) – this is necessary because our bookmarklet needs to interact with a REST API on the domain where the user will be sharing to (in this case, the host/domain where WebCenter).
- Proxy iframe (#4 in the diagram above) — this iframe is hidden off of the screen and is used simply to trigger events that happen on the parent. I’ll go into more detail as to why this is needed later.
Here’s the flow:
- Inserts a stylesheet to the page defining the style of the dialog box we’re going to create (#2).
- Defines a div container for us to insert our DOM elements into which makes it easier for cleanup when after the bookmarklet is used.
- Inserts the content iframe (#3) which points to bookmarklet.html on the WebCenter host.
- Inserts the proxy iframe (#4) which points to proxy_frame.html on the WebCenter host.
- At this point, the sharing dialog window has been initialized and the iframes have been rendered. Our bookmarklet communicates with the WebCenter REST API directly (#3). Before presenting the user with the “publisher” (sharing textarea), we need to determine if the user can access the REST API. Since our bookmarklet app is hosted on the same domain as the WebCenter app, we don’t can trigger the SSO system to authenticate the user if it’s needed (no fancy OAuth needed — good thing because WebCenter doesn’t support OAuth yet). Upon a successful SSO authentication, the iframe in #3 is reloaded and the REST API is called in order to paint the rest of the form.
- The only interaction left is when the user clicks the “Share” button. The Share button is purposefully inserted on the host page (not the iframe in #3). The reason for this is the share button will need to be able to trigger the dialog to close and also clean up all of the HTML that was inserted onto the page. You can’t do that if the button is inside the #3 iframe. However, this causes us another issue. How do we trigger the form submission in iFrame #3? Because of cross domain rules, you can’t trigger an event in another frame that’s from a separate domain. Enter iFrame #4, the proxy_frame.html. Before I explain how this works, go read Michael Mahemoff‘s excellent article about Cross-Domain Communication with iFrames — the technique I use is the “Window Size Monitoring” hack. The hack works like this…
- The main page (i.e., main parent) creates two iframes (#3 and #4), both of which reside on the same domain, but not necessarily the same domain as its parent.
- The first iframe contains the actual iframe you want the user to interact with (#3). The second iframe is the “proxy” iframe (#4). The proxy iframe’s purpose is to respond to events that the main parent triggers.
So, that’s the gist of it. Questions… ask below.