<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Martin Marinschek wrote On 4/13/2009 12:40 AM ET:<br>
<blockquote
cite="mid:5a99335f0904122140h471564d8k93d6e260338b645@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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_.
</pre>
</blockquote>
<br>
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:<br>
<br>
- FacesContext.isClientScriptingDisabled(). Returns false by default.<br>
- 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.<br>
- ClientBehavior.isFallbackAvailable(): May be called by renderers to
detect whether the behavior provides fallback content.<br>
- ClientBehavior.renderFallback(): May be called by renderers to render
fallback content<br>
<br>
We would also need to add similar methods on ClientBehaviorRenderer:<br>
<br>
- ClientBehaviorRenderer.isFallbackAvailable(): returns false by
default.<br>
- ClientBehaviorRenderer.renderFallback(): does nothing by default.<br>
<br>
And we would provide default implementations of the new methods on
ClientBehaviorBase:<br>
<br>
- ClientBehaviorBase.isFallbackAvailable: Gets the
ClientBehaviorRenderer, calls isFallbackAvailable().<br>
- ClientBehaviorBase.renderFallback(): Gets the ClientBehaviorRenderer,
calls renderFallback()<br>
<br>
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.<br>
<br>
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.<br>
<br>
Andy<br>
<br>
</body>
</html>