Open mdale opened 11 years ago
I don't think it should be part of this project. We may want to generalise some of our PHP classes and JS libraries so we could reuse them in other projects.
But it shouldn't be part of mwEmbed.
The main issue is how do we scale delivery of these components. The traditional infrastructure for components like the kRecord and KCW, is a flash swf delivery via the uiconf id, with associated configuration options. We don't have a good abstraction for that concept other than in mwEmbed.
We would need to build out:
Or we go in a direction where we promote lots of little projects hosting of bits and pieces of code that requires direct reference to JS & css files some hosted some not, and all invocation configuration is stored in-page.
And "KAF" handles everything else? ... i.e for example in KAF, we have the player display page, is that page making use of the embedCodeGenerator library? how is that being managed, git-external? exported copy of minified version ?
I tend to go with little libraries and helpers that we can re-use whenever we like. In case of EmbedCodeGenerator, I've used it in the KMC by just grabbing the latest minified version.
We would like to reuse the uiconf / flashvar / uiVar override delivery system, but for a playerless widgets.
A playerless widget could be things like:
Make use of the kWidget.api and getConfig tools.
The easiest way to implement this would probably be a special case on the iFrameClass site that loaded an empty player, but that seems a little verbose for packing in widgets of this nature, or we could just have a very simple object that had the json config in it for easy consistent access
Alternatively playerless widgets are always delivered with KAF, and we don't try to do any work arounds to support them being delivered via kWidget tools.