Issue Details (XML | Word | Printable)

Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: aschwart
Votes: 1
Watchers: 0

If you were logged in you would be able to see more operations.

Clarification of Facelets-only (non-JSP) functionality

Created: 24/Sep/09 08:53 AM   Updated: 08/Nov/13 09:15 PM
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: 2.3

Time Tracking:
Not Specified

File Attachments: 1. Text File validator06.jspx (3 kB) 01/Jul/10 06:52 AM - Ed Burns


Operating System: All
Platform: Macintosh

Issuezilla Id: 636
Status Whiteboard:

cat1 frame size_large importance_large

Tags: adf
Participants: aschwart, Ed Burns and rogerk

 Description  « Hide

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.

Ed Burns added a comment - 24/Sep/09 09:13 AM

Move to unscheduled target milestone

Ed Burns added a comment - 24/Nov/09 07:40 AM

Prepare to delete api subcomponent

rogerk added a comment - 24/Feb/10 08:19 AM

Target 2.0 Rev A

Ed Burns added a comment - 04/Mar/10 11:40 AM


Ed Burns added a comment - 15/Mar/10 01:44 PM


Ed Burns added a comment - 15/May/10 07:52 AM

These are valid 2.0 Rev a issues

Ed Burns added a comment - 24/May/10 12:55 PM

take ownership.

Ed Burns added a comment - 02/Jun/10 11:17 AM

Please make sure to see issue 1402.

Ed Burns added a comment - 07/Jun/10 08:34 AM

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 =; 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();; assertTrue(validatorResult.failureCount() == 0); }

Ed Burns added a comment - 07/Jun/10 08:34 AM

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

Ed Burns added a comment - 11/Jun/10 07:39 AM

Move to 2.1.

Ed Burns added a comment - 11/Jun/10 06:02 PM

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.


Ed Burns added a comment - 22/Jun/10 10:07 PM


Ed Burns added a comment - 24/Jun/10 02:41 PM

GlassFish 3.1 M6 at the latest.

Ed Burns added a comment - 24/Jun/10 02:50 PM

ADF issues targeted at GlassFish 3.1 M5

Ed Burns added a comment - 01/Jul/10 06:52 AM

Created an attachment (id=248)

Ed Burns added a comment - 08/Jul/10 07:20 AM

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

Ed Burns added a comment - 01/Sep/10 01:07 PM

Move to m6

Ed Burns added a comment - 01/Sep/10 01:07 PM

Must be done by September 30th.

Ed Burns added a comment - 10/Sep/10 01:31 PM

Move these to 2.2

Ed Burns added a comment - 13/Sep/10 09:00 AM


Ed Burns added a comment - 13/Sep/10 11:09 AM

remove changelog_2_1 keyword.

Ed Burns added a comment - 21/Aug/13 08:56 PM

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