[JAVASERVERFACES_SPEC_PUBLIC-636] Clarification of Facelets-only (non-JSP) functionality Created: 24/Sep/09  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File validator06.jspx    
Issuezilla Id: 636
Status Whiteboard:

cat1 frame size_large importance_large

Tags: adf

 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.



 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by rogerk [ 24/Feb/10 ]

Target 2.0 Rev A

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 15/Mar/10 ]

facelets

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 02/Jun/10 ]

Please make sure to see issue 1402.

Comment by Ed Burns [ 07/Jun/10 ]

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); }
Comment by Ed Burns [ 07/Jun/10 ]

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

Comment by Ed Burns [ 11/Jun/10 ]

Move to 2.1.

Comment by Ed Burns [ 11/Jun/10 ]

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

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

ADF issues targeted at GlassFish 3.1 M5

Comment by Ed Burns [ 01/Jul/10 ]

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

Comment by Ed Burns [ 08/Jul/10 ]

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

Comment by Ed Burns [ 01/Sep/10 ]

Move to m6

Comment by Ed Burns [ 01/Sep/10 ]

Must be done by September 30th.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 13/Sep/10 ]

changelog

Comment by Ed Burns [ 13/Sep/10 ]

remove changelog_2_1 keyword.

Comment by Ed Burns [ 21/Aug/13 ]

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Generated at Tue May 05 08:33:31 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.