THL Toolbox > Web Services & Interoperability > Web Service Possible Solutions
Web Service Possible Solutions
Contributor(s): David Germano, Andres Montano, Jed Verity.
III. Possible Solutions
THL’s applications are chiefly Ruby on Rails applications and XML databases. The Ruby on Rails applications all allow for easy provison of data in exports of XML or JSON. Thus standard web services providing data and metadata to external sites is quite straightforward. However, providing full functionality from these applications to mulitple web sites is a significant challenge.
1. I Frame
The easiest solution is to use an i-frame (note: The easiness should not be underestimated. An iframe would not only mean quicker implementation, it would also mean one plug-in for all applications instead of many and minimal - if any - need to update plug-ins as applications change). An i-frame allows for the application’s service to its full extent to appear in a rendered page within the external web site. You create another PHP page for the web site like you would for any tab, but the content would be an iframe that calls that content from the given RoR application (note: This isn't necessary. A div with a known id could parent a dynamically written iframe. In other words, the client puts "thl_frame" as the id of the div where he wants the iframe to come in. It would be better in some ways to have a dedicated page, but not necessary. FireFox used to have some problems with this, but not since v2). The RoR programmer needs to provide a view of his application without the THL wrapper, which requires some work. (note: This can be accomplished easily with Javascript, which can then hide designated wrapper elements, though a separate interface without these elements would be preferable.)
This is a very easy solution that involves little cost or time. However, there are significant drawbacks. First, there tend to be visual problems. The ugly border appearing by default around the i-frame can be styled away, but often there are other visual glitches which can disconcerting and difficult to eliminate. One of the worst is when you get a “double scroll bar”, namely a scroll bar within the i-frame, as well as the scroll bar of the browser window itself (note: these can all be mostly avoided). Second, the URL does not change in the browser’s address bar, such that users cannot bookmark pages within the i-frame for their later reference, or to send to other users. It is possible to make a link that says something like “Click here to get this page’s URL”, but users tend to ignore such links and instead expect the page to be bookmarkable in the standard way (note: You can have normal bookmarking, but it comes at the expense of normal forward/back nav. We think that if you have to sacrifice one, it is better to sacrifice bookmarks, but include a link to create one, which people admittedly fail to use. You would then have browser-native forward/back nav in most cases). Third, the content of the iframe and the overall page can’t talk to each other. Thus, for example, you can thus not have the title of the browser window change depending on what is being shown in the i-frame but you can’t do that. When you click on stuff in the iframe, only the iframe will change (note: Again, it is possible, but it comes at the expense of typical forward/back nav. We can thus have “back” and “forward” work on the browser, as long as we're not doing bookmarking or other communication from the iframe to the parent document, which would happen via the location bar, thus creating a kind of fake history that becomes difficult to navigate).
But can’t do ajax/java script calls because of security issues – can’t call ajax on a different server. And can’t do ajax calls between an i frame and a parent frame. Iframe has an href or source attribute, and you make that call to the application in question. All links to a Rails application where you want the content of the Rails application to show within a specified THL frame, you put a special class on those links, and the Java script goes through and identifies those classes, and when those links are clicked on, it replaces the content of the page with an iframe and loads the URL to the Rails app in that iframe, and you have the content of that Rails app in the iframe. Then you have the functionality of the Rails app in the inframe.
Though there are considerable limitations to iframes, they may make the most sense as the first stage of implementation. The idea is that there would be one Javascript plug-in on the client side and one on the server (THL application) side. On the server side, the plug-in would be responsible for detecting frames, writing the url of the client's stylesheet into the document, creating and presenting a bookmark link, parsing any other url information from its opener, possibly setting cookies to store information like the provided css url (though this would be better handled with sessions), and possibly hiding thl wrapper elements like the banner. There could also be a security feature to allow access only from certain domains, but this would also be better accomplished with server scripting.
On the client side, the plug-in would write the iframe into the designated div, pass any arguments to iframe documents (through the initial url), resize the iframe as necessary, and possibly receive messages from the application (via the location hash).
Here are the pros and cons of using iframes:
Cons
- Can't have both standard bookmarks and forward/back nav (without considerable expense). But can have one or the other relatively easily (see comments above).
- Back nav will have one limitation, which is that if you link from the i-frame to another page, the back button will go to the i-frame in its original page, rather than whatever page you were on when you linked to the other page
- Harder to control dimensions for users doing unexpected things, risking either truncated content or scrollbars.
- If the plug-in makes use of cookies, which it currently does and would if everything is to be handled by Javascript, many Safari users will have to be prompted to change their default security settings to allow cookies for framed domains.
Pros
- Faster, easier implementation.
- Minimal need to develop different plug-ins for different THL applications.
- Instant or fast feature roll-out for THL applications.
- Easier client-side custom css styling.
There is no question that the bookmark/nav issue is considerable. The question is: is it worth an extra $2500+ and the risk of further delay to overcome these issues now? I would suggest that it's not. We could have forward/back nav operating mostly standardly and a link for bookmarking, with the promise of more seamless functionality in future versions. This is not to say that all scenarios must have iframes - others will likely call for different solutions - but iframes could be the default approach.
The first step with iframes would be to try out the implementation of one application to see more fully its advantages and limitations.
2. Lightbox Popup
This gives the content in a popup window. However, the backgound page darkens when the window pops up, so that you the active window is very clear, and you cannot return to the browser window except by closing down the popup window. This solves the classic problems with popups – they litter your site with multiple versions, and you often can’t tell find the popup the second time around.
3. Fold-over Popup
This would be similiar to the lightbox popup but would be a fold over effect that darkens the original page while you consult it.
4. Standard Web service of XML Data
This involves the source application responding to a request for a specific set of datea by simply exporting out XML data with no functionality – content with no wrapper. It is then the other application’s problem how to handle, style, and generally present that data. This include a standard “more details” link that possibly then gives the fuller functionality in a lightbox popup.
This works effectively, but it only supplemental data provision. You are taking data from one place and fiting it into whatever application you are using at some time. This is not providing the structure, format, presenation to the same degree - just plugging the actual data in itself.
5. Two Rails Applications talking to each other
TBA.
6. Java Script Library Plugins
The most time intensive solution is to build Java Script plugins which a web site can add to their Java Script library. The plugins allow the web site in question to accept exported data (in XML or JSON format), and then emulate all of the host application’s functionality – navigation, searching, search results, browsing, etc. Thus the data and the behavior are provided as services, and the entire application is effectively ported over to a different context. There is one remaining problem – namely that you want the web pages to be able to style to some degree that data and its behaviors, so that it is visually integrated with its own standard forms of presentation. However i this case you are controlling every element. This can be dealt with as well by directing the style to a style sheet that can be easily edited.
