Hey Martin - Thanks for writing this up. (I decided to break the disabled JavaScript topic out into a separate email thread to make this easier to track.) Martin Marinschek wrote On 4/2/2009 3:24 AM ET: There are at least 3 different cases to consider: 1. Command components firing Ajax-based action events, eg: <h:commandButton> <f:ajax/> </h:commandButton> 2. Editable value holders firing Ajax-based valueChange events, eg: <h:inputText> <f:ajax/> </h:inputText> 3. Ajax-based events that other than #1 and #2, eg: <h:panelGroup> <f:ajax event="mouseOver"/> </h:panelGroup> Or even: <h:commandButton> <f:ajax event="mouseOver"/> </h:commandButton> Case #3 is the simplest, so let's look at it first. What is the correct fallback behavior for client behaviors/scripts that are invoked in response to user interface events such mouseOver/mouseOut, or say, focus/blur? I don't believe that there is any meaningful fallback content that we can provide here - a "Refresh" button isn't appropriate. My feeling is that for these cases, the correct fallback behavior is to do nothing. Application developers who need to build applications that run with JavaScript disabled should only leverage such events for progressive enhancement purposes - ie. such applications should not rely on these user interface events as the only means to access mission critical functionality. So, think we are okay for this particular case - I don't see the need to do anything here. Case #1 is more interesting... So what fallback behavior do we want when we are using Ajax to send an action event to the server in response to a click on a command component? The correct answer here is clear: when JavaScript is disabled, the command component should still deliver the action event, but via traditional form submission instead of over Ajax. Actually, this is exactly the fallback behavior that we have in the trivial <h:commandButton> example shown above... When Ajax is disabled, the <h:commandButton> will still submit - it just an HTML <input type="submit"> after all - and any registered action listeners will be called. So we've got a little graceful degradation happening already. Well, in this trivial case at least. However, there are at least two cases where we do not have a solution: - <h:commandButton> with <f:param> - <h:commandLink> (with our without <f:param>) Both of these cases currently require JavaScript execution for form submission purposes. Note that this is not in any way specific to Ajax or Behaviors, or even JSF 2.0. So we've got a more fundamental problem here. Leaving Ajax/Behaviors aside for a moment - how would we go about solving more basic cases such as supporting <h:commandLink> when JavaScript is disabled? The solution requires two pieces: - We need some way to detect when JavaScript is disabled. - Components that care need to render alternate content when JavaScript is disabled. For example, if we had a way for the <h:commandLink>'s renderer to determine that JavaScript is disabled, then the renderer could fall back to rendering an HTML <input type="submit"> instead of a link with an onclick handler. The <f:param> case is a bit trickier. I suppose that the link/button renderer could spit parameter values out as hidden fields instead of using JavaScript to include these values in the form dynamically. The drawback of course is that the hidden fields will be submitted with every postback, not just when the corresponding button is clicked. Or perhaps we could use an HTML <button> element and encode the parameters into the button's value attribute? I believe that Spring Faces has solved this problem (Jeremy - can you comment)? Does cs-JSF deal with this? Any other frameworks provide solutions for this? In any case, the point is that for the command/action case, the solution really lies in the component renderer - this is not an Ajax/Behavior issue. If we solve the generic problem of supporting <h:commandLink> and <h:commandButton> with <f:param> when JavaScript is disabled, then this is sufficient to address the Ajax case as well. Case #3 is the trickiest... There are actually two sub-cases here: 3A. The Ajax request is optional - Ajax is used to progressively enhance the editable value component. 3B. The Ajax request is required - Ajax is used to provide functionality that the end user needs in order to complete some task in the application. An example of 3A might be Ajax-based validation. The application should of course re-validate any data when the form is submitted. Disabling JavaScript is not a problem here, since the Ajax-based functionality is an enhancement, not a required feature. The main use case for 3B is master-detail components. A common case is using a select component as the master and updating the detail contents based on the user's selection. For example, the user selects a car manufacturer from an Ajax-enabled <h:selectOneMenu>. This populates a second <h:selectOneMenu> with the appropriately filtered set of car models. If JavaScript is disabled, and the <f:ajax event="valueChange"> is the only means provided by the application to trigger the population of the second select component, any users who have disabled JavaScript will be stuck. There are a range of possible solutions here: i. Give Behaviors the ability to render arbitrary contents before/after/during component rendering. One concern that I have about this approach is that it means that the Behavior implementation needs to be familiar with the component - and possibly the component's content - to know when to render, or whether to render anything at all. For example, if the Behavior is attached to an <h:selectOneMenu>, then it might want to render a "Refresh" button. However, if the Behavior is attached to an <h:commandButton> (or some other component, like an <h:panelGrid>), then no "Refresh" button should be rendered. I would prefer that we come up with a solution where the component Renderer decides when/where to have the Behavior render its fallback content, since the component Renderer knows both whether it requires fallback content at all and also knows where the best placement of the fallback content might be. ii. Provide a more targeted Behavior API that component renderers can use to ask a Behavior to render fallback content. Instead of allowing Behaviors to render arbitrary content before/after/during component rendering, we would instead provide a couple of new methods, perhaps on ClientBehavior (not sure about the method names): - public boolean isFallbackAvailable() - public void renderFallback(BehaviorContext) Or, alternatively, we can add these on a new FallbackClientBehavior interface (extends ClientBehavior). Components/renderers that want to render fallback content (eg. input/select components) would call renderFallback() at the appropriate point in order to insert the Behavior's fallback content into the response. Components/renderers that do not want to render fallback content (eg. pretty much everything other than the input/select components) wouldn't bother calling this. iii. Let the component renderers provide fallback content. The idea here is that the input/select component renderers already have enough information available to determine whether or not fallback content (ie. a "Refresh" button) is required. (Well, there still is the question of how to detect whether JavaScript is disabled, but leaving that aside for the moment). So, for example, the <h:selectOneMenu> renderer could very easily check to see: - Whether it has any ClientBehaviors attached for the "valueChange" event. - Whether any of these ClientBehaviors are "submitting" behaviors. In the event that: - The <h:selectOneMenu> has a submitting valueChange ClientBehavior attached, and... - JavaScript is disabled The <h:selectOneMenu> could then render its own "Refresh" button. No need for the Behavior to do anything. Okay, so after writing this option up, it occurs to me that not all submitting behaviors would require fallback content to be rendered - eg. the presence of an Ajax-based validator (case #3A above) should not cause a "Refresh" button to appear. So if we want to leave it up to the component renderer to provide fallback content, we would need some API on the ClientBehavior (maybe a new hint), that the component renderer would check to see whether fallback content is actually needed. iv. Don't provide any automatic solution - let the application provide a solution. The idea here is that if we provide some easy way to determine whether JavaScript is disabled (eg. a method on the FacesContext), page authors who care about this can do something along the lines of: <h:selectOneMenu> <f:ajax/> </h:selectOneMenu> <!-- Provide a refresh button, but only when scripting is disabled --> <h:commandButton value="Refresh" rendererd="#{facesContext.scriptingDisabled}"/> Think that's it for possible solutions. If we want to enhance the Behavior API to support fallback content rendering, I strongly prefer option (ii) over option (i). This solution seems simpler, more in line with the existing ClientBehavior model, and requires that fewer assumptions be built into Behavior implementations. I think this is a better split of responsibilities between the component and the Behavior (ie. component decides when/where fallback content is needed, Behavior produces the fallback content). BTW, an important question that we should consider is whether JSF itself should provide a facility for detecting whether client-side scripting is enabled. This could be very useful - ie. could allow us to solve long-standing problems. For example, if we have a way to detect when JavaScript is disabled, seems like we could provide an <h:commandLink> that works when JavaScript is disabled fairly easily (fall back to an <input type="submit">). As for how to go about detecting whether JavaScript is disabled, I was thinking we would do something along these lines: - FormRenderer spits out a <script> that dynamically adds a hidden field with some well known name. - On postback, we check to see whether this hidden field is present - If the hidden field is present, we know that scripting is enabled. Yay. - If the hidden field is not present, we assume that scripting is disabled. Of course, this means that we cannot detect whether JavaScript is enabled until the first postback is performed. Is there some way to get around this? Martin or Jeremy - I know you guys have provided solutions for this sort of thing - please let jump in if you have any suggestions. Andy

Dan Allen wrote On 4/3/2009 3:42 PM ET: This reminds me of a topic that I've been meaning to raise... Seems like we are all happy with the new JSR-314-OPEN mailing list. However, in addition to opening the EG mailing list for observation, I think it would be helpful to also introduce an open list where community members can provide feedback in a more visible manner - ie. instead of closed JSR-314-COMMENTS - how about a JSR-314-COMMENTS-OPEN with write access for both EG and community members? I think that this would encourage community members to more actively follow EG/spec progress (and provide feedback of course). What do people think about trying to get something along these lines set up? Andy

That would be excellent, especially since *we* don't even get to see that list. Sent from my iPhone http://www.jsfcentral.com http://www.Virtua.com On Apr 3, 2009, at 10:05 PM, Andy Schwartz <andy.schwartz(a)ORACLE.COM&gt; wrote:

an *obvious* (whatever that means) +1 from me! regards, Martin On 4/4/09, Simon Lessard <Simon_Lessard(a)dmr.ca&gt; wrote: -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces

Hi Martin - Martin Marinschek wrote On 4/7/2009 8:43 AM ET: Thanks for reading through my long email and for the comments! :-) Sorry I wasn't able to follow up on this last week... Cool, makes sense. Right, agree completely. When I used the term "master-detail", I should have said that I was using this loosely - ie. I just meant any case where updating one (master) component results in other (detail) components somewhere else on the page being updated (or hidden/shown). In the initial non-generic/Ajax-specific design we did have assumptions based on the component type - ie. <f:ajax> only supported "action" events for command components and "valueChange" events for editableValueHolders. This was awful - and one of the main reasons why we decided to move forward with the generic Behavior solution. With the current solution, the component identifies the set of supported events as well as the default event via the ClientBehaviorHolder interface. This allows ClientBehavior implementations (such as AjaxBehavior) to avoid making assumptions based on the component type, which is important for interoperability - ie. this allows us to write ClientBehavior implementations which are not specific to a known set of components - but can work with arbitrary components from different component providers (eg. RichFaces, IceFaces, Trinidad, ADF Faces, etc...). Right. The component renderer knows: - Whether or not a particular event exposed via the ClientBehaviorHolder contract is worthy of fallback behavior. For example, the renderer for <h:inputText> knows that the "valueChange" event is special compared to, say, the "mouseOver" event - ie. that fallback behavior should be provided (if available) for the "valueChange" event, but not for the "mouseOver" event. - Where fallback content should be placed (if available). - Whether any ClientBehaviors are available for an event that warrants fallback behavior. As you point out, however, the component renderer does not currently know whether a ClientBehavior or ClientBehaviors attached to such events are capable of producing fallback content. So, if we want to support fallback content rendering in a generic way, we could add two new methods to ClientBehavior: 1. public boolean isFallbackAvailable() 2. public void renderFallback(BehaviorContext) ClientBehaviors that are capable of providing fallback content would implement isFallbackAvailable() to return true. Component renderers that care about providing fallback content would: - Check to see whether JavaScript is disabled (need some standard API for this). - If so, check to see whether they have any ClientBehaviors attached to events that warrant fallback content (eg. "valueChange" for <h:inputText>). - If so, check to see whether any of these ClientBehaviors have fallback content available by calling isFallbackAvailable(). - If fallback content is available, figure out where to render the fallback content (this may involve altering the component's own rendered content - eg. may mean rendering rendering additional layout elements or styles). - Finally, call renderFallback() to allow the ClientBehavior to produce the fallback content (eg. a "Refresh" button). If it is too late to get something like this in for 2.0 - ie. if we cannot add these two methods to ClientBehavior, then we can still solve this problem in 2.1 by introducing a FallbackClientBehavior interface. This means that renderers will need to do an "instanceof FallbackClientBehavior" test when trying to determine whether fallback content is available, but this seems reasonable to me. I know that the 2.0 spec has been handed off to the JCP - not sure how much leeway we have to add new APIs at this point. Were you thinking of new methods on FacesContext? Perhaps something like: - public boolean isClientScriptingDisabled() - public void setClientScriptingDisabled() This might be useful even if we did not provide any automatic detection for the disabled scripting case, since it would at least provide a standard way for server-side code (components/renderers/behaviors) to easily determine whether to script-free content is required. I do think it is possible to do everything that we discussed here in 2.1. If it is too late to support this in 2.0, perhaps we should add "disabled JavaScript support" to our 2.1 feature list - not just for ClientBehavior/AjaxBehavior - but for the more general <h:commandButton>/<h:commandLink> case as well. Just curious - how do you do the forward? Yeah - seems like something along these lines would work. Thanks for suggesting this solution! We could consider encapsulating this in a "noscript" component that renders the appropriate content. 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. Andy

I don't want to interrupt a good discussion, so just take note of my comment here. Styling buttons is not always reliable. Some browsers ignore styles completely, so generally I won't recommend this approach. Spring Faces renders a button first and then swaps in a link if JavaScript is available (by using JavaScript). I was impressed by the idea, but a non-technical user noticed the "flash" it creates in some browsers that don't execute DOM manipulation fast enough. Therefore, I like the idea of deciding up front of a browser is going to support JavaScript or not and then choose the most optimal rendering from then on out (i.e., render normally once it's determined that JavaScript is enabled rather than using these hacks on every request). -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.

Sorry to be so late in chiming in here, but I thought I'd add my two cents since this is something we do think about quite a bit in the Spring web tier as you guys have already alluded. At a high level, you are talking about two fundamentally different approaches: graceful degradation vs. progressive enhancement. I'll avoid getting into too long of a theoretical diatribe on the relative value of the two approaches and just refer to one of my preferred sources for further explanation: http://accessites.org/site/2007/02/graceful-degradation-progressive-enhan... We take the progressive enhancement approach in Spring Faces and we also generally advocate its use to the whole of the Spring community whether using JSF or not. One of the main reasons we favor progressive enhancement vs. graceful degradation is because it is rather difficult to conclusively determine ahead of time whether JavaScript is enabled or not, and even if you are able to do so successfully, it still does not guarantee that the JavaScript environment will be available and in a certain state throughout the whole of the client-side interaction. Browsers in general (including IE) have improved in this regard, but IE6 for example (which is still, sadly, in fairly wide use) is particularly bad at recovering in the case of a JavaScript error on the page, and the other browsers still are not in any way fool-proof in this regard. In some cases, it's really not the fault of the browsers, but of poorly behaving components that don't respect the open nature of the JavaScript sandbox. If you render all of the components on a page in such a way that they assume the JavaScript environment is available and in a certain state, and the script of one of the components higher up on the page fails badly or perhaps just misbehaves in some way that causes those assumptions to break, you are likely to end up with your users cursing you for putting a broken UI in front of them. Alternatively, if you render a fully functional DOM and add rich behavior progressively (which may include mutating the foundation in some way, as we do with the Spring Faces commandLink), even if something breaks your script, you are much more likely to be left with components that still function in the face of unexpected failures. Now, achieving the right balance of CSS, HTML, and scripts such that the transition is not jarring to the user (as Dan cited below) can be difficult, but it can be done. We intentionally did not implement a smoother transition in the Spring Faces demo app because we wanted it to be clear what is happening when describing the progressive enhancement techniques to our community. Now is progressive enhancement the right approach for every single application? Not necessarily. For many internal intranet applications, which I think right now are still the sweet spot for JSF, an approach that assumes more about the user's environment is perfectly acceptable. But I for one am more interested in expanding the possibilities of JSF being used to create public facing applications that reach the widest possible audience of users. To do that, IMHO, a functional HTML foundation should not be a fallback, but rather the default. I am generally not in favor of baking either approach directly into the JSF APIs (though note that when using progressive enhancement, there is usually no need to do so in the first place). I would love to see a progressive enhancement approach taken in the basic default components (most notably commandLink), but I'm not sure that necessarily belongs in the spec either as it is more of an implementation detail. Thanks, Jeremy On Apr 13, 2009, at 2:22 AM, Dan Allen wrote:

Hi Jeremy, Well, if done in the body onload-callback, it should definitely not hinder the visual appearance of the page. I do see that if we only follow progressive enhancement, there is not even the need for a boolean state variable which indicates JavaScript is enabled or not. However, I am not sure that for JSF this will fly. Two examples which I would see as problematic: 1) Let's look at the simple case of the commandLinks: the problem here is that links and buttons are no one-by-one replacement. First, a link can have params, a button not. How do you handle this with JavaScript only? Indeed, you will need to have different rendering on the server to get this working - and a different handling of the decoding. As the different handling of the decoding implies a not too small performance overhead, I would really rather enable this for 2% of the user-base, and not for everyone. Second, a link can have free text and image combinations as children, a (submit) button not (and buttons are not an option, as we all know). So no approach in rendering a JSF commandLink as an input type=submit will be perfect - and I don't see how such a link can be rendered into valid HTML so that it will work with progressive enhancement (I believe the only choice you have is to render different markup on the server, and even then, it will not be perfect). 2) let's look at a more complex example: cs-JSF provides a split-table for users of the component library. This split-table will (in the very near future) be horizontally and vertically scrollabe, with fixed row and column headers - something developers of highly dynamic intranet web-applications do obviously expect from a component library. What do we do in this case? To support the JavaScript in the browser, we really have to render the table differently on the server: we render not one table, but several tables. When JavaScript is switched off, only one table should be rendered, and the horizontal and vertical splitting would just not work. It gives me headaches to think about the solution for this with progressive enhancement. To sum it up, while I do think that progressive enhancement is the way to go for internet facing applications which need to cater for a heterogenous user base, I do think that with JSF, we will definitely need the method of graceful degradation as well - at least from time to time. And I do believe that without a proper solution for the two issues with the command-link I highlighted above we will (sadly) need graceful degradation for the command-link as well - but I would be very, very happy if you could prove me wrong, so please do ;) regards, Martin ok, agreed. regards, Martin

Martin Marinschek wrote On 4/13/2009 12:40 AM ET: 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

Oh, one other comment... Martin Marinschek wrote On 4/13/2009 12:40 AM ET: Yes, agree completely, we definitely want to optimize for the JavaScript-enabled case. Andy

On 4/3/09, Andy Schwartz <andy.schwartz(a)oracle.com&gt; wrote: I am absolutely for insertChildren and insertFacets, and relocation! Ed, do you think we could do this change? a very reasonable idea! regards, Martin