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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
