Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Facelets/VDL
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Macintosh

    • Issuezilla Id:
      636
    • Status Whiteboard:
      Hide

      cat1 frame size_large importance_large

      Show
      cat1 frame size_large importance_large
    • Tags:

      Description

      I would like to see the spec provide more explicit documentation of exactly which new features are not
      available in JSP. I sent the following two proposals to the EG list:

      1. Let's update the spec to state specifically what functionality (down to the tag/tag library level) is not
      supported in JSP.

      It is possible that this information is already present, but if not, I would like to see a section that
      contains a list of all of the new tags that were added in JSF 2 that are specific to Facelets (ie. not
      available in JSP).

      2. Let's update the Facelets PDL docs to identify tags that are not present in JSP.

      For example, the PDL doc for f:ajax should state that it is not available in JSP.

      Regarding #1... I think it is important to have this information available in a centralized location, where
      it can be easily found/understood by JSP users. #2 should also help to avoid confusion.

        Activity

        Hide
        Ed Burns added a comment -

        Move to unscheduled target milestone

        Show
        Ed Burns added a comment - Move to unscheduled target milestone
        Hide
        Ed Burns added a comment -

        Prepare to delete api subcomponent

        Show
        Ed Burns added a comment - Prepare to delete api subcomponent
        Hide
        rogerk added a comment -

        Target 2.0 Rev A

        Show
        rogerk added a comment - Target 2.0 Rev A
        Hide
        Ed Burns added a comment -

        cat1

        Show
        Ed Burns added a comment - cat1
        Hide
        Ed Burns added a comment -

        facelets

        Show
        Ed Burns added a comment - facelets
        Hide
        Ed Burns added a comment -

        These are valid 2.0 Rev a issues

        Show
        Ed Burns added a comment - These are valid 2.0 Rev a issues
        Hide
        Ed Burns added a comment -

        take ownership.

        Show
        Ed Burns added a comment - take ownership.
        Hide
        Ed Burns added a comment -

        Please make sure to see issue 1402.

        Show
        Ed Burns added a comment - Please make sure to see issue 1402.
        Hide
        Ed Burns added a comment -

        This is not a technically difficult issue, but it is a time consuming one.

        I think the best way to do it is empirically. I'm writing an HtmlUnit test suite that exercises the jsp
        accessible supported/unsupported status of the big ticket new features in JSF2.

        So far it's looking like this:

        public void testUnsupportedFeaturesAreUnsupported() throws Exception

        { // These features are not implemented in JSP assert500Response("/faces/jsf2jsp/head-gives-500.jspx"); assert500Response("/faces/jsf2jsp/body-gives-500.jspx"); assert500Response("/faces/jsf2jsp/outputScript-gives-500.jspx"); assert500Response("/faces/jsf2jsp/outputStylesheet-gives-500.jspx"); assert500Response("/faces/jsf2jsp/button-gives-500.jspx"); assert500Response("/faces/jsf2jsp/link-gives-500.jspx"); assert500Response("/faces/jsf2jsp/resource-ELResolver-gives-500.jspx"); assert500Response("/faces/jsf2jsp/ajax-gives-500.jspx"); assert500Response("/faces/jsf2jsp/event-gives-500.jspx"); assert500Response("/faces/jsf2jsp/metadata-gives-500.jspx"); }

        public void testSupportedFeaturesAreSupported() throws Exception

        { // These features are implemented in JSP HtmlPage page = getPage("/faces/jsf2jsp/commandButton-parameter-children-gives-hidden- fields.jspx"); HtmlSubmitInput button = (HtmlSubmitInput) page.getElementById("reload"); page = button.click(); String text = page.asText(); assertTrue(text.contains("name01=value01")); assertTrue(text.contains("name02=value02")); page = getPage("/faces/jsf2jsp/resources.jspx"); text = page.asXml(); assertTrue(text.contains("duke.gif")); assertTrue(text.contains("vLibrary")); assertTrue(text.contains("2_01_1")); assert200Response("/faces/jsf2jsp/selectManyJsf2Features.jspx"); Test validatorTest = ValidatorTestCase.suite(); TestResult validatorResult = new TestResult(); validatorTest.run(validatorResult); assertTrue(validatorResult.failureCount() == 0); }
        Show
        Ed Burns added a comment - This is not a technically difficult issue, but it is a time consuming one. I think the best way to do it is empirically. I'm writing an HtmlUnit test suite that exercises the jsp accessible supported/unsupported status of the big ticket new features in JSF2. So far it's looking like this: public void testUnsupportedFeaturesAreUnsupported() throws Exception { // These features are not implemented in JSP assert500Response("/faces/jsf2jsp/head-gives-500.jspx"); assert500Response("/faces/jsf2jsp/body-gives-500.jspx"); assert500Response("/faces/jsf2jsp/outputScript-gives-500.jspx"); assert500Response("/faces/jsf2jsp/outputStylesheet-gives-500.jspx"); assert500Response("/faces/jsf2jsp/button-gives-500.jspx"); assert500Response("/faces/jsf2jsp/link-gives-500.jspx"); assert500Response("/faces/jsf2jsp/resource-ELResolver-gives-500.jspx"); assert500Response("/faces/jsf2jsp/ajax-gives-500.jspx"); assert500Response("/faces/jsf2jsp/event-gives-500.jspx"); assert500Response("/faces/jsf2jsp/metadata-gives-500.jspx"); } public void testSupportedFeaturesAreSupported() throws Exception { // These features are implemented in JSP HtmlPage page = getPage("/faces/jsf2jsp/commandButton-parameter-children-gives-hidden- fields.jspx"); HtmlSubmitInput button = (HtmlSubmitInput) page.getElementById("reload"); page = button.click(); String text = page.asText(); assertTrue(text.contains("name01=value01")); assertTrue(text.contains("name02=value02")); page = getPage("/faces/jsf2jsp/resources.jspx"); text = page.asXml(); assertTrue(text.contains("duke.gif")); assertTrue(text.contains("vLibrary")); assertTrue(text.contains("2_01_1")); assert200Response("/faces/jsf2jsp/selectManyJsf2Features.jspx"); Test validatorTest = ValidatorTestCase.suite(); TestResult validatorResult = new TestResult(); validatorTest.run(validatorResult); assertTrue(validatorResult.failureCount() == 0); }
        Hide
        Ed Burns added a comment -

        Because this issue is labor intensive, I'm wondering if we should push it to 2.1?

        Show
        Ed Burns added a comment - Because this issue is labor intensive, I'm wondering if we should push it to 2.1?
        Hide
        Ed Burns added a comment -

        Move to 2.1.

        Show
        Ed Burns added a comment - Move to 2.1.
        Hide
        Ed Burns added a comment -

        Copy this from Neil Griffin's google doc linked from issue 714.

        Availability of f:validateBean and f:validateRequired in JSP

        Section 10.4 outlines the f: namespaced tags that are only applicable to Facelets (and not JSP). In that
        section, f:validateBean, and f:validateRequired are listed. However, they are both listed as working with
        JSP as well (kind of like f:validateRegex), as can be seen from the JSP TLDDocs [1].

        According to Dan Allen: "those tags only work partially in JSP. Yes, they work as single field validators.
        But the branch validator capability does not work (wrapping the validator tag around a branch). The
        later feature is Facelets only. So the validators do have their feet in both ponds, but only Facelets has full
        support. I suppose we could mention this tidbit in the JSP section."

        I agree with Dan that it should be mentoned in the JSP section, but also, that f:validateBean and
        f:validateRequired belong in both Section 10.4 and 9.4, with the limits of their functionality described in
        each section.

        [1] https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/jsp/index.html

        Show
        Ed Burns added a comment - Copy this from Neil Griffin's google doc linked from issue 714. Availability of f:validateBean and f:validateRequired in JSP Section 10.4 outlines the f: namespaced tags that are only applicable to Facelets (and not JSP). In that section, f:validateBean, and f:validateRequired are listed. However, they are both listed as working with JSP as well (kind of like f:validateRegex), as can be seen from the JSP TLDDocs [1] . According to Dan Allen: "those tags only work partially in JSP. Yes, they work as single field validators. But the branch validator capability does not work (wrapping the validator tag around a branch). The later feature is Facelets only. So the validators do have their feet in both ponds, but only Facelets has full support. I suppose we could mention this tidbit in the JSP section." I agree with Dan that it should be mentoned in the JSP section, but also, that f:validateBean and f:validateRequired belong in both Section 10.4 and 9.4, with the limits of their functionality described in each section. [1] https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/jsp/index.html
        Hide
        Ed Burns added a comment -

        triage

        Show
        Ed Burns added a comment - triage
        Hide
        Ed Burns added a comment -

        GlassFish 3.1 M6 at the latest.

        Show
        Ed Burns added a comment - GlassFish 3.1 M6 at the latest.
        Hide
        Ed Burns added a comment -

        ADF issues targeted at GlassFish 3.1 M5

        Show
        Ed Burns added a comment - ADF issues targeted at GlassFish 3.1 M5
        Hide
        Ed Burns added a comment -

        Created an attachment (id=248)
        jsf-ri/systest/web/validator06.jspx

        Show
        Ed Burns added a comment - Created an attachment (id=248) jsf-ri/systest/web/validator06.jspx
        Hide
        Ed Burns added a comment -

        I discovered that f:viewParam exists in the JSP jsf_core.tld. Does it really work?

        Show
        Ed Burns added a comment - I discovered that f:viewParam exists in the JSP jsf_core.tld. Does it really work?
        Hide
        Ed Burns added a comment -

        Move to m6

        Show
        Ed Burns added a comment - Move to m6
        Hide
        Ed Burns added a comment -

        Must be done by September 30th.

        Show
        Ed Burns added a comment - Must be done by September 30th.
        Hide
        Ed Burns added a comment -

        Move these to 2.2

        Show
        Ed Burns added a comment - Move these to 2.2
        Hide
        Ed Burns added a comment -

        changelog

        Show
        Ed Burns added a comment - changelog
        Hide
        Ed Burns added a comment -

        remove changelog_2_1 keyword.

        Show
        Ed Burns added a comment - remove changelog_2_1 keyword.
        Hide
        Ed Burns added a comment -

        The specification of StateManagementStrategy is too tight and needs to be loosened to allow greater flexibility of implementation.

        Show
        Ed Burns added a comment - The specification of StateManagementStrategy is too tight and needs to be loosened to allow greater flexibility of implementation.
        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.

          People

          • Assignee:
            Unassigned
            Reporter:
            aschwart
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: