2

We're converting from ANGEL to D2L.  We've created JavaScript-based widgets that use the $SECTION_ID$ token to tell the script what course it is running from.  In Desire2Learn the equivalent would be the replacement string {OrgUnitCode}.  We'd like to just use that replacement string, but they don't work properly in course page (where most of my widget useage is).  Is there some other way to find out what course a JavaScript widget is running in?

Here is an example the code for one of our widgets that a user would paste into a page in their course: 

<script type="text/javascript" data-id="NotablePAD540" section="{OrgUnitCode}">
     var DAT = DAT || {}; if (!DAT.n) { (function (d) {
     var f = d.getElementsByTagName('SCRIPT')[0], s = d.createElement('SCRIPT'); s.async = true;
     s.type = 'text/javascript'; s.charset = 'utf-8'; s.src = '//dev.notable.vudat.msu.edu/n.js'; 
     f.parentNode.insertBefore(s, f); }(document)); }; DAT.n = 1; </script>

Each notepad has a unique ID, this code snippet example is for a notepad with the id 540.  The dynamic bit, {OrgUnitCode}, is what would separate out data, allowing me to use the same snippet in multiple course offerings and have the data stored separately.

user2274759
  • 55
  • 3
  • Just trying to clarify: Where is it that an instructor would paste this javascript? Is it actually in a widget on the course home page? – Cadmium Apr 26 '13 at 16:16
  • Usually they would be placed in pages the Content tool, not homepage widgets. – nlounds Apr 26 '13 at 17:05

1 Answers1

2

If the case is purely to have a widget on course home page that contains dynamic information the most effective solution is probably to use a "Remote Plugin Widget".

These can be set up by administrators uing the "Manage Remote Plugins" tool.

They Remote Plugins effectively just combine LTI launches into iframes and make them available as widgets when you are configuring home pages(or in other areas of the system). There are examples posted of how to use this for richer server side applications.

The LTI launch itself passes information on where it is being launched from (i.e. context related information).

In your case it looks like just hosting a static page containing javascript would work. Then you could use the javascript to inspect the query string. (A bit tricky to test the LTI signatures from javascript safely, if you care about trust at that point...)

Also, Valence APIs (the GET calls) can be used from the javascript if you need to supplement with other information that is available.

Cadmium
  • 566
  • 3
  • 10
  • Our usual use case is for our snippets to be used throughout course content pages, not in homepage widgets. I was hoping not to have to rely on inspecting the query string, fearing that it wouldn't be a reliable method. I don't know if it would be consistent everywhere within the course, all different views, etc. Would it be the value of 'ou' that you would suggest grabbing from the query string? – nlounds Apr 26 '13 at 17:13
  • Yeah, the value of OU is your out of the box way of doing this today. Parsing this might be fragile (how the ou is passed is not part of the standard versioned apis) but in practice will probably work. Are your instructors going to have to end up dropping the javascript block into all their course files where they want this behaviour? – Cadmium Apr 26 '13 at 20:12
  • Yes, instructors drop the JavaScript where they want an instance of the tool. Using the Insert Stuff button, at least they can do the initial insert without having to look at the page source. We'd love to have WYSIWYG integration, but for now it is copy and paste. – nlounds Apr 29 '13 at 20:18