VideoPlayer refactoring thoughts

[Clark, Colin]

Hey all,

We unpacked this issue in a bit more detail today in the IRC chat room. Here's a link to the logs:

http://wiki.fluidproject.org/display/fluid/fluid-work+IRC+Logs-2012-01-26

The short version:

1. Our current Video Player design isn't quite right: we're missing a strategy component that represents the HTML5-specific behaviour of the player. Right now, this logic is spread across two places: the Video Player parent component and the fluid.videoPlayer.media component. In the long run, this will also allow us to introduce other strategies--the YouTube player, JWPlayer or FlowPlayer, etc.

2. Especially once this refactoring is in place, the role of the Video Player parent component--like many top-level components--is to serve as an aggregator of options and configuration for its many cooperating children.

3. The Video Player parent component is probably best as an ordinary View, and the Captioner and Controls components should handle their own separate, self-contained templates using the Renderer.

Hope this helps,

Colin


On 2012-01-26, at 10:47 AM, Cheetham, Anastasia wrote:

> 
> Michelle and I had a discussion this morning about the current implementation of the VideoPlayer as a rendererComponent and whether or not that was appropriate. I'd like to run our thoughts by the list, to see if anyone can contribute to the discussion.
> 
> The VideoPlayer parent component is currently implemented as a rendererComponent, but that seems a bit overkill:
> 
> - In the default case (i.e. when the Player's own custom controls are used)
>  - every selector is ignored,
>  - the renderer tree is empty and
>  - the entire template is "passed through" untouched.
> 
> - In the (likely rare) case where the integrator has selected native controls
>  - the renderer tree includes only the video element, for the purpose of adding the "controls" attribute (using a decorator)
>  - the selector for the custom controls is NOT ignored, but it is not included in the tree, so the renderer strips that markup out.
> 
> The choice between these two options is based on code paths within the VideoPlayer component, not through IoC (FLUID-4567, which is what led to this re-examination).
> 
> 
> What Michelle and I are proposing is:
> 
> 1) Convert the VideoPlayer parent component to a viewComponent which will load the template and insert it into the DOM "manually."
> 2) Pull the markup for the custom controls out of the main template into a separate template controlled by the "customControls" subcomponent (a rendererComponent)
> 3) Create a "nativeControls" subcomponent responsible for modifying the <video> element to add the "controls" attribute necessary for native controls.
> 
> We are aware that loading multiple separate templates has higher overhead, but we think that in this case, it's still the best solution. We'd love to hear everyone's thoughts on this.
> 
> 
> -- 
> Anastasia Cheetham     Inclusive Design Research Centre
> acheetham at ocadu.ca           Inclusive Design Institute
>                                        OCAD University
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

---
Colin Clark
Lead Software Architect,
Inclusive Design Research Centre, OCAD University
http://inclusivedesign.ca