javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-761

Submitting forms destroys bookmarkable URLs on re-render or validation failure.

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Navigation
    • Labels:
      None
    • Environment:

      Operating System: Linux
      Platform: PC

    • Issuezilla Id:
      761
    • Status Whiteboard:
      Hide

      size_large importance_large

      Show
      size_large importance_large

      Description

      <h:form> calls ViewHandler.getActionURL() in order to resolve the <form
      action="..."> attribute.

      The problem here is that when a page is accessed via a bookmarkable URL, the
      form action does not use that bookmarkable URL for postbacks. This means that as
      soon as a form is submitted, the page query-parameters are lost, meaning that
      the resource (while it may still be functionally equivalent) is no longer
      capable of bookmarking.

      The argument "you shouldn't bookmark after a form submit:"

      Bookmarking after a form submit should be just as valid as bookmarking that
      resource the first time the page was accessed via GET-based navigation.

      This loss of bookmarkability occurs when a form is submitted, validation fails,
      or the page is re-rendered without re-directing and including page params
      through a faces-config.xml complex navigation case.

      A simple use-case to show the behavior: /faces/index.xhtml

      <?xml version='1.0' encoding='UTF-8' ?>
      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
      <html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core">

      <f:metadata>
      <f:viewParam name="foo" value="#

      {bar}" />
      </f:metadata>

      <h:link outcome="index.xhtml" value="go to bookmarkable URL" >
      <f:param name="foo" value="bar" />
      </h:link>

      <h:form>
      <h1>#{bar}

      </h1>
      <h:commandButton value="destroy bookmarkable URL"
      action="?include-page-params=true" />
      </h:form>
      </html>

      My proposed solution for this issue is to require that forms either:

      A. re-render the URL of the page with which it was accessed.
      B. require that forms call ViewHandler.getBookmarkableURL() instead of
      ViewHandler.getActionURL(), and also require that any page parameter supplied
      during the initial request, be preserved.

        Activity

        Hide
        rogerk added a comment -

        For now re-target for 2.2.
        If time permits may revisit for 2.1.

        Show
        rogerk added a comment - For now re-target for 2.2. If time permits may revisit for 2.1.
        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        Darious3 added a comment -

        OmniFaces has implemented a solution for this. See http://showcase-omnifaces.rhcloud.com/showcase/components/form.xhtml

        It uses encodeBookMarkeableURL, but doesn't include any GET parameters that aren't also view parameters: http://code.google.com/p/omnifaces/source/browse/src/org/omnifaces/component/input/Form.java?name=1.2

        Show
        Darious3 added a comment - OmniFaces has implemented a solution for this. See http://showcase-omnifaces.rhcloud.com/showcase/components/form.xhtml It uses encodeBookMarkeableURL , but doesn't include any GET parameters that aren't also view parameters: http://code.google.com/p/omnifaces/source/browse/src/org/omnifaces/component/input/Form.java?name=1.2
        Hide
        Ed Burns added a comment -

        Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
        Hide
        Manfred Riem added a comment -

        Setting priority to Minor

        Show
        Manfred Riem added a comment - Setting priority to Minor

          People

          • Assignee:
            Unassigned
            Reporter:
            lincolnbaxter
          • Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated: