Progressive Enhancement in the framework

[Antranig Basman]

On 31/01/2013 08:50, Michelle D'Souza wrote:

Hi, Michelle - thanks for this summary. I think some of the details of the proposal as stands aren't 
workable, since there's no method for the framework to be able to guess that a context name that it sees 
corresponds to an "enhancement check that hasn't run yet" or one that is missing for any number of other 
reasons that cause it not to be there. The model behind context tags is that they are "eager", in that every 
tag which might, for example, ever form part of the static environment should appear there as early as 
possible. Is there a reason other than a potential efficiency worry that led to the idea that "only checks 
they care about run"? Most of these context checks in my experience consist of a simple boolean comparison 
or existence of a particular global object so the efficiency worries shouldn't be very strong.

In fact, the scheme you've proposed leads to lower efficiency over all since it will impact the resolution 
of every mismatched demands block over all time - on finding a missing name anywhere in the tree, the scheme 
requires a boolean check every time in order to determine that it doesn't correspond to a "free function by 
that name".

I think when we proposed this feature requirement we had in mind something quite simple - just a declarative 
structure that formalised and automated the workflow that we already had in the videoPlayer, 
progressiveEnhancement and elsewere. Do you think you and Justin could draw up a declarative structure for 
this and a draft implementation?

Cheers!
Antranig

>
> 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
>
>
>
>