In it's current form, the SCORM Player (specifically the pop-up window generated when launching a module) requires the tool to be embedded in an iFrame. For Sakai 11+ this means that the SCORM tool IDs need to be added to the following sakai.property to ensure that the portal forces the tool into an iFrame, rather than inlining it:
If the SCORM Player tool IDs are not included in the above sakai.property, the result is that the pop-up window generated when launching a module will be wrapped in the portal navigation markup. See the attached screenshots for an illustration.
The code that decides whether to inline or not lives in core Sakai code, in portal's SiteHandler. We need to identify and modify the relevant code here so that the SCORM Player's module pop-up windows are not wrapped in the portal navigation, but are also not embedded in an iFrame.
The main reason we want to accomplish this is so we stop having to fight with the iFrame boundaries. For instance, when the tool is embedded in an iFrame, anything inside the iFrame cannot access resources from outside the iFrame. So, things like JavaScript and CSS provided by portal can't be used within the iFrame. This paradigm forces us to then import the JavaScript and CSS resources we need within the iFrame duplicating these resources which is an efficiency and performance hit.
By inlining the tool, we can do away with a lot of code within SCORM Player to add the necessary portal resources within the iFrame.
In it's current form, the SCORM Player (specifically the pop-up window generated when launching a module) requires the tool to be embedded in an iFrame. For Sakai 11+ this means that the SCORM tool IDs need to be added to the following sakai.property to ensure that the portal forces the tool into an iFrame, rather than inlining it:
If the SCORM Player tool IDs are not included in the above sakai.property, the result is that the pop-up window generated when launching a module will be wrapped in the portal navigation markup. See the attached screenshots for an illustration.
The code that decides whether to inline or not lives in core Sakai code, in portal's
SiteHandler. We need to identify and modify the relevant code here so that the SCORM Player's module pop-up windows are not wrapped in the portal navigation, but are also not embedded in an iFrame.The main reason we want to accomplish this is so we stop having to fight with the iFrame boundaries. For instance, when the tool is embedded in an iFrame, anything inside the iFrame cannot access resources from outside the iFrame. So, things like JavaScript and CSS provided by portal can't be used within the iFrame. This paradigm forces us to then import the JavaScript and CSS resources we need within the iFrame duplicating these resources which is an efficiency and performance hit.
By inlining the tool, we can do away with a lot of code within SCORM Player to add the necessary portal resources within the iFrame.