Martin Marinschek wrote On 4/13/2009 12:40 AM ET:
Right.  If we provide standard APIs for tracking the disabled scripting
state (eg. FacesContext is/setClientScriptingDisabled()), then we could
simply leave it up to the app developer to figure out when to call
setClientScriptingDisabled(true), at least for the moment.  Of course,
it would be good to provide a standard mechanism for automatically
detecting the disabled scripting scenario, though I imagine this would
need to wait until 2.1.
    

yes, probably - but the API methods might make sense to be added right
now, if we also have the fallback-methods on the behaviours in place.
We could then say that an implementation _may_ support a
JavaScript-free fallback and JavaScript detection, and for the next
version, we could change this to _must_.

Okay, so just to recap...  If we are considering tackling this in 2.0 (and, of course, I am not sure that this is even a possibility at this point), we would be adding the following new APIs:

- FacesContext.isClientScriptingDisabled().  Returns false by default.
- FacesContext.setClientScriptingDisabled().  The JSF implementation wouldn't necessarily call this in 2.0, though application or component developers could add their own JavaScript detection logic and call this.
- ClientBehavior.isFallbackAvailable(): May be called by renderers to detect whether the behavior provides fallback content.
- ClientBehavior.renderFallback(): May be called by renderers to render fallback content

We would also need to add similar methods on ClientBehaviorRenderer:

- ClientBehaviorRenderer.isFallbackAvailable(): returns false by default.
- ClientBehaviorRenderer.renderFallback(): does nothing by default.

And we would provide default implementations  of the new methods on ClientBehaviorBase:

- ClientBehaviorBase.isFallbackAvailable: Gets the ClientBehaviorRenderer, calls isFallbackAvailable().
- ClientBehaviorBase.renderFallback(): Gets the ClientBehaviorRenderer, calls renderFallback()

Think that's it... We wouldn't even have to provide much in the way of implementation, ie. we could enhance AjaxBehaviorRenderer to provide fallback content (eg. a "Reset" button), but we could also simply spec that this is implementation-specific, at least for 2.0.

If we postpone until 2.1, we would end up adding the same APIs, but instead of adding methods to ClientBehavior, presumably we'll need to add a FallbackClientBehavior sub-interface.

Andy