William & Mary
Close menu Resources for... William & Mary
Popular Topics
Suggested Results
News Events
Apply Visit Request Info
W&M menu close William & Mary
University Communications
University Web & Design

Creative Content Consumption

Presented at Cascade Server Users Conference, 2010

Andrew Bauserman
Senior Web Architect
William & Mary
[[wabaus]]

Background and Assumptions:

W&M produces content that lives outside of Cascade Server. This content might be hosted within YouTube, Flickr, WordPress, Twitter, FourSquare or Google Maps and Open Street Map.

Theory:

In the last 2 years, Hannon Hill has charted a roadmap focusing on building Cascade Server's core competency as an enterprise content management system. As part of this roadmap, Cascade Server has added to the existing Publishing and Database Publishing options a new "Connector" framework, currently including Twitter and WordPress connectors. These permit content within Cascade Server to be "pushed" to external services. It's a wise application of a pet phrase of applying this roadmap and furthering the notion "do what you do best and link to the rest" (Jeff Jarvis)...  Cascade Server can not only export content to best-in-class services across the Web; it can also ingest content from across the Web, providing dynamic content within the look, feel, and navigation of your site.

Practice:

A cursory tour of the W&M website will show plenty of direct links to 3rd party services. In fact, our Communities page has nothing but links to external sites.

We are no more interested in reimplementing these services inside Cascade Server than Hannon Hill is. The use-case we're addressing is not to disinter-mediate Twitter or Flickr as a service; but instead to incorporate the content we are generating on those services selectively and judiciously within our primary web site.

Flickr holds our photos, and allows tagging, sharing and commenting. Flickr also provide an RSS feed and slideshow widgets. Likewise YouTube for videos, and Twitter for short messages.

Implementation:

What I hope to do is set up a conceptual framework for looking at our external content and deciding how best to incorporate it within our Cascade-managed web site. We'll do this using selected examples of different methods, and see how they compare.

1) Client-side JS/Embed within a WYSIWYG content region

By pasting the Flash/JavaScript code provided by a 3rd party system within the HTML region of a Cascade page we can place a Flickr slideshow, Google Map or YouTube video on virtually any page.

Pros:

  • runs on most browsers
  • previews in Cascade
  • easy to get/paste code from remote service
  • interactivity possible (dependent on service)

Cons:

  • requires Javascript/Flash client, trust of remote host
  • accessibility ? (dependent on remote service)
  • Cascade users need "Edit HTML Source" button
2) Generated Client-side JS/Embed

The code we pasted for a YouTube video of Flickr Gallery in the previous example generally looks the same for any given video or gallery, except for one or two critical parameters (for instance, the video id for YouTube). What if we create a data-defintion where the user provides parameter(s) like a YouTube video id. Then we can hack some code in Cascade (XSLT/Velocity) to merge those parameters into the appropriate Javascript or Object/Embed code (or omit the code if no parameter is provided).

Pros:

  • runs on most browsers
  • previews in Cascade
  • relatively easy to get/paste parameters from remote service
  • Cascade users do *not* need "View HTML Source" button
  • interactivity possible (dependent on service)

Cons:

  • initial work required by Cascade admin for each service/content-type
  • requires Javascript/Flash client, trust of remote host
  • accessibility? (may provide more control; mostly dependent on remote service)
2b) Generating the Client-side JS/Embed using Javascript

What if, instead of transforming the parameters into the object/embed code using XSLT within Cascade, we pass the parameters in a {[special format]} along to the browser and use something like jQuery to transform it on-the-fly as the page loads?

Pros:

  • same as above

Cons:

  • same as above, but admin generates code in JS vs XSLT
3) RSS and XSLT

Cascade is pre-configured with a content block designed to fetch remote XML data such as an RSS feed. Link that block to a page-region and tie it to an XSLT format that does RSS-to-HTML transformation.

Pros:

  • runs on ALL browsers
  • previews in Cascade
  • many services (Twitter, WordPress) provide RSS feeds
  • could be extended to other XML schemas
    (from Atom on the simple side, to ODF for the brave/insane)
  • feed is effectively "cached" as published by Cascade to web server

Cons:

  • not all services provide RSS feeds
  • limited interactivity (display content w/ links)
  • limitation of spec./fields within RSS
  • initial work required by Cascade admin for each broad class of feed
    (e.g., RSS from Twitter vs. Flickr may have different display needs)
  • extending to more complex XML file types may take significant effort
  • published page may be out of date (needs scheduled publishing)
3b) RSS via Javascript

As we did in the last YouTube example, we can pass the feed url to the client to fetch and transform using Javascript (our own, or a 3rd party script).

Errata:

  • In the original presentation, I failed to mention same origin policy for consuming content within one HTML page from another HTTP resource. There are methods for pulling remote RSS feeds using document.domain DOM property (same top-level domain), reverse-proxy, or SimplePie. Apologies for this oversight in the presentation.

Pros:

  • as above, with these differences...
  • runs on most browsers
  • may be more timely (loaded on-the-fly by the end-user)
  • previews within Cascade

Cons:

  • as above, with these differences...
  • lack of caching (increased hits to the feed from distributed users)
  • page may take longer to render due to heavy Javascript demands
  • same origin policy limitations
4) JS, AJAX and dynamic/generated iFrames

As the last example shows, we can consuming http content within a page using client-side requests. We can go beyond this and build our own stub-code/application using, for example, an AJAX framework.

Pros:

  • runs on most browsers
  • interactivity possible
  • lots of available JS/AJAX libraries to handle lots of data types (from RSS and iCal to the Twitter API)
  • may or may not preview in Cascade, depending on content locations ?
    (JS may need to assemble Cascade-preview URLs within Cascade vs. web URLs after publishing)

Cons:

  • may require Javascript client, trust of remote host
  • interactivity dependent on code/service
  • high up-front investment by Cascade admin & web developer
    (building an external service with a JS stub that calls the larger JS applet that interacts with remote system)
  • may or may not preview in Cascade ?
    (does JS assemble Cascade-preview URLs within Cascade vs. web URLs after publishing?)

Examples:

  • OK - I'm cheating on this one. We don't have anything homegrown in this category, so here's the closest we've got...
  • https://www.wm.edu/about/search/
    This one is JS/AJAX code provided by Google, creates the iFrame on-the-fly. The idea is that all of the code to do the interaction lives in some Javascript file that we're including on the page.
  • Bronto.com feedback form for the Mason School of Business is a simple iFrame - not so much AJAX
    (live link, please don't SPAM them: https://mason.wm.edu/comments/ )
5) Server-side scripting

Use server-side (PHP/cURL) content fetching to insert a web-app onto a Cascade template/page. Use something like Method #2 to pass parameter(s) to a small/stub PHP code block in Cascade. Stub code calls functions/objects/web-services using an included library.

For example, we can use a PHP/cURL script to fetch a user response form, submit the form, and display the results within the Cascade-managed page/template (header, footer, menu, breadcrumbs).

Pros:

  • runs on ALL browsers
  • relatively easy to get/paste parameters from remote service
  • interactivity possible
  • allows "skinning" of interactions not inherent to Cascade

Cons:

  • does NOT preview in Cascade (no PHP interpreter)
  • interactivity dependent on code/service
  • high up-front investment by Cascade admin & web developer
    (building an external service with a PHP stub that calls a larger PHP applet that interacts with remote system)
5+4) Adding AJAX within the PHP webapp

It's possible to have the PHP/cURL loaded webapp utilize AJAX for interactions. It adds to the complexity of the initial programming, and may require a JS-enabled client that trusts the remote host. We haven't yet gone down this route. But I wanted to mention that the 2 aren't mutually exclusive.