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

[Martin Marinschek]

+1 from me,

regards,

Martin

On 4/13/09, Andy Schwartz <andy.schwartz at oracle.com> wrote:
> 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
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces