Progressive Enhancement in the framework

[Michelle D'Souza]

Hi there,

Justin and I have been pairing on FLUID-4794 which involves improving the current Progressive Enhancement infrastructure. We've chatted a bit with Colin and Yura and have some ideas for a solution that we would like some feedback on. Please see below for details.

Thanks,

Michelle




Goals for Progressive Enhancement: 

1. Accommodate differences in a) browser feature support (i.e. HTML5 features) and b) client and server environments (i.e. Node versus browser) by determining what features are available in the current context and delivering the best possible experience.
2. Support the ability for component creators to add new feature checks easily.
3. Check only the features required for the components being used in a particular application or on a particular page.


Current Implementation:

Our current implementation is being used by the Uploader component. The implementation consists of a predefined set of features that get checked and put into the static environment on page load, and a component that takes an ordered set of features and returns the first available feature. The Uploader is wrapped by this component in order to deliver the best possible experience based on the context in which it is being used. 

There are some issues with the current implementation that we would like to improve upon. 

1. The use of a wrapper component complicates the API for users of the underlying component.
2. There is currently no easy way to extend the existing set of feature checks.
3. All of the existing feature checks are run when Progressive Enhancer is used, whether or not we care about them.
4. We require a separate instance of the Progressive Enhancer for every feature set we care about. 


Proposed solution:

The solution we have been talking about involves using demands blocks as a way to state what features are required for a particular context. For example, Uploader has three possibilities that we want to deliver in this priority order: Binary XHR, Flash and Single File. In order to specify this, we would put the Single File component in the defaults block and have demands blocks that would deliver the other implementations when it's possible. One complexity comes up when we try to specify the priority order of Binary XHR and Flash. We would naturally have individual demands blocks to deliver each of those implementations, however, we would also require a third demands block that would deliver Binary XHR when both Binary XHR and Flash are available. 

This would work today, however, there is more that we need to do to meet goals 2 and 3 above. Currently, we have several checks that we perform when Progressive Enhancement loads and we store the results of the checks in the static environment.  This works well, because by the time we need to actually determine which features are available (at the time of demands resolution), the checks have been done. This issue we run into, is providing a way for people to add new checks and only have checks they care about run. For all of this to work, we need to have the relevant checks performed prior to component initialization and demands resolution. The correct time is likely at the point of demands registration. This requires us to modify the framework to recognize when an action needs to be carried out early and actually do that action. One possibility is to keep the demands API exactly as it is now, but have the framework do a little extra when it encounters a context that it does not know about yet. Instead of just progressing, it could look for a free function by that name and execute it. This might look something like this: 

fluid.demands("myComponent", ["browser.html5Track"], {
	funcName: "myComponent.html5Impl"
});

browser.html5Track = function () {
	// determines whether or not html5 Track is available
};

// Framework puts something in the static env to denote that we've checked for html5Track and whether or not we have it




------------------------------------------------------------------------
Michelle D'Souza
Senior Inclusive Developer
Inclusive Design Research Centre, OCAD University




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20130131/6a6a9b34/attachment.htm>