[jsr-314-open] JavaScript disabled support [Was: Outcome of JSFDays discussions]

[Andy Schwartz]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090413/b3567be6/attachment.html