Loading HTML5 plugins (On-Page / Iframe) #108

ranyefet opened this Issue May 5, 2012 · 4 comments


None yet
2 participants

ranyefet commented May 5, 2012

The problem:

Currently with v1.6.x series, we have few limitations with our plugins loader.

  1. We need to define module name in hard-coded LocalSettings.php
  2. We load lots of loader.js files which we might have no use for.
  3. When loading external plugins, you need to define the js files using the following:
<Plugin id="fooBar" width="0%" height="0%" includeInLayout="false" loadingPolicy="onDemand" 
        iframeHTML5Js1="myfooBarHtml5IframePlugin.js" iframeHTML5Js2="myfooBarHtml5IframePlugin2.js"

Or using uiVars to load files:

    <var key="IframeCustomPluginJs1" value="externalResources/IframeCustomPluginJs1.js" />
    <var key="IframeCustomPluginJs2" value="externalResources/IframeCustomPluginJs2.js" />
    <var key="IframeCustomPluginCss1" value="externalResources/IframeCustomPluginCss1.css" />

The solution:

I like to suggest to following changes for v1.7:

  1. Remove the hard-coded modules list in LocalSettings.php
  2. Create a mapping file for our core plugins that will map: uiConf plugin ID => html5 module name / path
  3. Only load modules that defined in the uiConf

External Plugins:

We need to have built in script loader that will help plugins authors to load libraries that the plugins depends on and manage execution order. maybe something like: http://requirejs.org/

Lets say I'm building an onPage plugin that make use of few libraries, lets say Underscore, Backbone and jQuery.
We need to have built in functionality to help plugin authors to load these libraries in the right order.

mdale commented May 7, 2012

I agree, and think most of this is in the scope of the new resource loader refactor. I think a cascading implied path is good, and the common loader.js logic could be generalised for most of the plugins.

We do have inline dependency handling in resource loader for inside the iframe plugins. i.e mw.load( 'foo', 'bar', function(){ /* execute code now that foo and bar are loaded */ );

For on page plugins we some of this dependency loading support in the kWidget calls that we use to load the library. We can expose them with more elegant requirejs like syntax with the restriction that they be fully qualified urls.

@mdale mdale pushed a commit that referenced this issue Jun 5, 2012

Michael Dale more plugin refactoring, related to #108
-- adds named plugin names for kaltura uiConf components. 
-- refactors kaltura plugins to use short init calls.

ranyefet commented Aug 12, 2012

We should take a look into this issue when working on #47 #151 for now pushed to v1.7.x

mdale commented Sep 17, 2012

some related changes were made in #224 and #226

mdale commented Oct 29, 2012

I think we can essentially close this bug; per the html5-ps and html5 onpage paths support and per the relatively automatic mapping present in 1.7 ( we no longer hard code module list in the LocalSettings.php ) and we list plugin id mappings in a php manifest.

We essentially let on-page plugins dictate secondary loading conditions. For example the description box is in charge of ensuring it has jQuery: https://github.com/kaltura/mwEmbed/blob/master/kWidget/onPagePlugins/descriptionBox/descriptionBox.js#L62

We may think of a way to specify defined on page dependencies in the uiConf ... ie. requiresJS="jQuery,jQuery.ui,underscore,backbone" etc. whatever we have defined in our resource loader module list to be loaded on-page ... but probably beyond the scope of this bug; should be part of the onPage future architecture discussion, and we have to tread lightly per lessons of "on-page" jQuery dependency checking.

mdale closed this Oct 29, 2012

@einatr einatr added a commit that referenced this issue May 28, 2015

@einatr einatr new HLS plugin built from 2.32 branch (fixes for FEC-3582, FEC-3415 a…
…nd PLAT-2016) includes PRs #106, #107, #108, #109 and #118
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment