VideoPlayer refactoring thoughts

[Cheetham, Anastasia]

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