[JAVASERVERFACES_SPEC_PUBLIC-1029] viewParam value lost after validation errors Created: 02/Aug/11  Updated: 04/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: arjan tijms Assignee: arjan tijms
Resolution: Unresolved Votes: 15
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: state, validation

 Description   

As every UIInput component, UIViewParameter normally retains its value after a postback. If there's any kind of validation error on the page (unrelated to the UIViewParameter) the model to which the UIViewParameter is bound will correctly not be updated. However, when the component is subsequently encoded this model will be queried for its value.

In effect, the retained value is typically lost when the model is in request scope.

The following reproduces this:

viewparam.xhtml
<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 id="id" name="id" value="#{viewParamBean.id}"/>
    </f:metadata>

    <h:body>

        <h:messages />

        #{viewParamBean.id} <br/>

        <h:form>
            <h:inputText value="#{viewParamBean.text}" >
                <f:validateLength minimum="2"/>
            </h:inputText>

            <h:commandButton value="test" action="#{viewParamBean.actionMethod}"/>
        </h:form>

    </h:body>
</html>
ViewParamBean.java
@ManagedBean
@RequestScoped
public class ViewParamBean {

    private long id;    
    private String text;

    public void actionMethod() {

    }

    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = id;
    }

    public String getText() {
        return text;
    }

    public void setText(String text) {
        this.text = text;
    }    
}

If you call the Facelet with viewparam.xhtml?id=12 it will display the 12 onscreen. If you then input something valid, e.g. aaaaa, the id will disappear from the URL, but keeps being displayed on screen (owning to the stateful nature of ui components). As soon as any validator error occurs (e.g. entering a), the id will be permanently lost. Entering valid input afterwards will not bring it back.

The implementation of encodeAll of UIViewParameter in Mojarra highlights what's happening:

UIViewParameter.java
public void encodeAll(FacesContext context) throws IOException {
    if (context == null) {
        throw new NullPointerException();
    }

    // if there is a value expression, update view parameter w/ latest value after render
    // QUESTION is it okay that a null string value may be suppressing the view parameter value?
    // ANSWER: I'm not sure.
    setSubmittedValue(getStringValue(context));
}

public String getStringValue(FacesContext context) {
    String result = null;
    if (hasValueExpression()) {
        result = getStringValueFromModel(context);
    } else {
        result = (null != rawValue) ? rawValue : (String) getValue();
    }
    return result;
}

Because hasValueExpression() in getStringValue() is true, this will try to get the value from the model. But in case the model is request scoped it will not have any value for this request, since validation has just failed and thus no value has ever been set. In effect, the stateful value of UIViewParameter is overwritten by whatever the model returns as a default (typically null, but this depends on the model of course).

Expected behavior: After validation errors occur, the model should not be consulted (e.g. as implemented by Mojarra's HtmlBasicRenderer#getCurrentValue)



 Comments   
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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1078] Have DataModel implementations registrable Created: 28/Feb/12  Updated: 21/Aug/15

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: lightguard Assignee: arjan tijms
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Text File changebundle.txt     Text File changebundle3.txt     Text File changebundle4.txt     Zip Archive newfiles.zip     Zip Archive newfiles.zip     Zip Archive newfiles3.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1380 Utilize @FacesDataModel for existing ... Open
is related to JAVASERVERFACES_SPEC_PUBLIC-1103 UIRepeat and UIData supports Iterable Resolved

 Description   

There have been issues and discussions about having a DataModel implementation in the spec for java.util.Set. This is certainly a good thing. Better though, would be to have a way (via annotation and/or faces-config.xml) to register an implementation and the type of Object it supports. This would clean up code in UIData and also allow for expansions of DataModel types without having to update the spec.



 Comments   
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.

Comment by arjan tijms [ 11/Jul/15 ]

Expanded @FacesDataModel support to UIRepeat

Comment by arjan tijms [ 13/Jul/15 ]

Applied to 2.3 trunk,
svn commit -m "Initial commit for https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1078, Have DataModel implementations registerable, r=mriem"
Sending jsf-api/src/main/java/javax/faces/component/UIData.java
Adding jsf-api/src/main/java/javax/faces/model/FacesDataModel.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/CdiExtension.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/CdiUtils.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/DataModelClassesMapProducer.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/FacesDataModelAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/component/UIRepeat.java
Adding test/javaee8/facelets
Adding test/javaee8/facelets/pom.xml
Adding test/javaee8/facelets/src
Adding test/javaee8/facelets/src/main
Adding test/javaee8/facelets/src/main/java
Adding test/javaee8/facelets/src/main/java/com
Adding test/javaee8/facelets/src/main/java/com/sun
Adding test/javaee8/facelets/src/main/java/com/sun/faces
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child1.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child11.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child111.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child11Model.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child1Model.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child2.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child21.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child21Model.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child2Model.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/DataBacking.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Parent.java
Adding test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/ParentModel.java
Adding test/javaee8/facelets/src/main/webapp
Adding test/javaee8/facelets/src/main/webapp/WEB-INF
Adding test/javaee8/facelets/src/main/webapp/WEB-INF/beans.xml
Adding test/javaee8/facelets/src/main/webapp/WEB-INF/glassfish-web.xml
Adding test/javaee8/facelets/src/main/webapp/WEB-INF/web.xml
Adding test/javaee8/facelets/src/main/webapp/datatableCustomDataModel11.xhtml
Adding test/javaee8/facelets/src/main/webapp/datatableCustomDataModel111.xhtml
Adding test/javaee8/facelets/src/main/webapp/uirepeatCustomDataModel11.xhtml
Adding test/javaee8/facelets/src/main/webapp/uirepeatCustomDataModel111.xhtml
Adding test/javaee8/facelets/src/test
Adding test/javaee8/facelets/src/test/java
Adding test/javaee8/facelets/src/test/java/com
Adding test/javaee8/facelets/src/test/java/com/sun
Adding test/javaee8/facelets/src/test/java/com/sun/faces
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/DataTableCustomDataModelIT.java
Adding test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/UIRepeatCustomDataModelIT.java
Sending test/javaee8/pom.xml
Transmitting file data ..............................
Committed revision 14837.

Comment by Manfred Riem [ 13/Jul/15 ]

Can you please address the following PMD issues

UIRepeat.java:61, UnusedImports, Priority: Normal
Avoid unused imports such as 'com.sun.faces.cdi.CdiUtils'.

DataModelClassesMapProducer.java:40, TooManyStaticImports, Priority: Normal
Too many static imports may lead to messy code.

Note it might be better to move the @interface into its own file instead of doing it as an inner class.

Comment by arjan tijms [ 14/Jul/15 ]

Avoid unused imports such as 'com.sun.faces.cdi.CdiUtils'.

I'll look at this one right away. I have the same checks running locally but this one slipped through (likely because of some noise regarding a couple of existing warnings)

DataModelClassesMapProducer.java:40, TooManyStaticImports, Priority: Normal
Too many static imports may lead to messy code.

I'll take a look at this one too. What's the limit currently set too?

Note that for JDK8 code we may want to increase the limit or remove the rule (if possible). JDK8 code puts a lot more emphasis on static imports and this is considered good practice. The PMD rule is likely still based on JDK5 style code. JDK8 provides a lot of goodies in utility classes such as Collectors (e.g; Collectors::toList that typical code does not write out fully (see basically all Oracle examples for Stream based code).

Note it might be better to move the @interface into its own file instead of doing it as an inner class.

Do you mean DataModelClassesMapProducer.DataModelClasses here? The initial idea was to keep it private to the parent class, since it was just a way to prevent an ambiguous situation when injecting Map. Code in the API project obtains the map by name only, so no new types were needed to be introduced there.

However, UIRepeat is in the impl project and could make use of utility code, so it may make sense indeed now to move it to a top level class. Additionally, if/when the API project can make use of utility code this would also allow it to obtain the map in a more strongly typed way.

Comment by arjan tijms [ 14/Jul/15 ]

Applied to 2.3 trunk,
svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1078, Several cleanups, r=mriem"
Adding jsf-ri/src/main/java/com/sun/faces/cdi/DataModelClasses.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/DataModelClassesAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/DataModelClassesMapProducer.java
Sending jsf-ri/src/main/java/com/sun/faces/facelets/component/UIRepeat.java
Sending test/javaee8/facelets/src/main/java/com/sun/faces/test/javaee8/facelets/Child2Model.java
Sending test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/DataTableCustomDataModelIT.java
Sending test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/UIRepeatCustomDataModelIT.java
Transmitting file data .......
Committed revision 14843.

Comment by arjan tijms [ 15/Jul/15 ]

Applied to 2.3 trunk,
svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1078, Excluded tests for WLS 12.2.1, r=mriem"
Sending test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/DataTableCustomDataModelIT.java
Sending test/javaee8/facelets/src/test/java/com/sun/faces/test/javaee8/facelets/UIRepeatCustomDataModelIT.java
Transmitting file data ..
Committed revision 14861.





[JAVASERVERFACES_SPEC_PUBLIC-947] Relative Resources Created: 09/Mar/11  Updated: 04/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 24
Labels: None
Σ Remaining Estimate: 5 days Remaining Estimate: 5 days
Σ Time Spent: 2 hours Time Spent: Not Specified
Σ Original Estimate: 5 days Original Estimate: 5 days

Attachments: Zip Archive sample.zip     Zip Archive sample_broken.zip    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-884 Support library prefix in resource URLs Reopened
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900 Images resources in css with relative... Closed
is duplicated by JAVASERVERFACES-1189 #{resource['...']} not usable in <ui:... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1079 Add method ResourceHandler.isResource... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-548 Resource localization is too rigid an... Sub-task Closed Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-884 Support library prefix in resource URLs Sub-task Reopened Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-996 The resources folder should be either... Sub-task Closed Ed Burns  
Status Whiteboard:

size_small importance_medium


 Description   

https://issues.apache.org/jira/browse/MFCOMMONS-29

The features of this ResourceHandler include the following:

  • relative paths between resources (css files referencing images
    without using #resource['..'])
  • caching resources in the client (disabled if ProjectStage == Development)
  • GZIP compression and local cache in tmp dir (disabled if
    ProjectStage == Development)
  • i18n (supporting country code and language).

In addition, it does NOT support ValueExpressions in resource files
for performance reasons.

The most important feature, in my opinion, is how the resource URL is
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css

... because it permits resources referencing other resources without
#

{resource['...']}

(e.g. css files referencing images or other css
files). With the standard ResourceHandler this is 1) annoying if you
have to change the files you get from your designer and 2) a
performance bottleneck, because resources with ValueExpressions are
not cached and also regenerated for each request.

Furthermore, the resource URL contains the locale and thus you have no
problems with cached resources if a users changes the locale, because
he/she will get a new URL and thus a new resource (the right one).



 Comments   
Comment by Jakob Korherr [ 15/Apr/11 ]

add duplicate links.

Comment by Jakob Korherr [ 13/Jun/11 ]

Just found out that ICEFaces actually provides a tool for processing url() references in css files which are served by JSF 2.0. For example, this tool creates url(#

{resource['org.site.lib/images/background.png']}

) out of url(../images/background.png).

This shows the big impact of this issue, I think.

See http://wiki.icefaces.org/display/ICE/ACE+CSS+URL+Mapping for more details!

We seriously need to fix this with JSF 2.2! Such (annoying) preprocessing should not be necessary.

Comment by Hanspeter Duennenberger [ 26/Aug/11 ]

Hi Jakob,

it would be usefull if there was a way to specify resources depending on the active ProjectStage - e.g. for css and Javascript files, to allow using packaged resources normally but uncompressed css/javascript when ProjectStage is set to Development.

I was discussing this once with someone and we ended up in a possible solution for that to put additional includeProjectStage/excludeProjectStage condition attributes on @ResourceDependency annotation and probably also same attributes on outputStylesheet/outputScript tags.

Might be this ends up in an additional independent issue, but as you are going to work on ResourceHandling anyway I feel adding it here is ok.

regards
Hanspeter

Comment by lu4242 [ 29/Aug/11 ]

In MyFaces and Tomahawk a custom hack is used to check if the project stage is Development and if a resource under META-INF/internal-resources (or in tomahawk META-INF/uncompressed-js-resources), just take this instead the compressed version used in Production stage.

I believe that it could be more simple to assume a "mirror uncompressed" location, and in practice use some plugin to compress the resources, and add the logic on the default (or custom) ResourceHandler algorithm.

EB> This approach breaks down when there is not a 1:1 mapping between
EB> compressed and non-comporessed resources. For example, when you
EB> want all your JS in one compressed file at Production time, and want
EB> several smaller, non-compressed files, at Development time.

Comment by Jakob Korherr [ 04/Sep/11 ]

Hi Hanspeter,

This is a very, very nice idea! I will prototype that in my relative-resource-handler at apache-extras (see http://code.google.com/a/apache-extras.org/p/relative-resource-handler/).

Also: Since I will have more time in the next two weeks, I really do hope to get some work done for the spec!

Regards,
Jakob

Comment by Hanspeter Duennenberger [ 03/Oct/11 ]

Hi Jakob,

any progress here?

I wanted to add something about the ProjectStage dependent resources. There might be two options for it:

1. use a project stage dependent resource path in the jar (similar to Locale handling with fallback). This is useful if the resource is the same name but only compressed for production, e.g.

myJs/some.js
myJs/production/some.js             (compressed some.js)

2. because the JS files may get pretty big, we would like to use multiple JS files for development but combine/compress a number of such JS files to one for production. This means the number of resource dependencies change depending on project stage.

myJs/funct-a.js
myJs/funct-b.js
myJs/funct-c.js
myJs/{production/}funct-all.js      (compressed combination of funct-*.js files)

So for example, it should be possible to state one component needs funct-a.js and funct-b.js when in project stage Development and only funct-all.js when in project stage Production.

I think possibility 1 is a little closer to what Leonardo mentioned about the MyFaces specific hack.
I really would like to have a specified way to handle project-stage specific resources, this might need some discussion in expert group though.

Cheers
Hanspeter

Comment by Jakob Korherr [ 06/Oct/11 ]

Hi Hanspeter,

Currently I am trying to convince a professor at Vienna university of technology to let me write about the relative resource handler for my bachelor thesis. If this will be accepted, I will have a lot more time for the resource handler.

The idea is really very, very great and I'd like to do some prototyping here. However, I don't know if we should really follow a convention-over-configuration approach. I am actually not sure if we can find a convention for the resource name that will fit in most scenarios. Maybe we need some configuration mechanism here...

Regards,
Jakob

Comment by Hanspeter Duennenberger [ 09/Feb/12 ]

Hi all.

For multiple skins or theme support it will be necessary that the resource path may contain an optional skin or theme-path part.

 Skin-one
 /resources/skin-one/css/main.css

 Skin-two
 /resources/skin-two/css/main.css

The reference to this resource could be:

 <h:outputStylesheet name="main.css" library="css" />

I have kind of such an implementation, but it is probably to much integrated with our Skin interface. It should be a more general solution.

Regards
Hanspeter

Comment by Jakob Korherr [ 14/Feb/12 ]

Hi hanspeter,

You are totally right! In my resource handler I called it "support for multi-tenancy", however, this is not implemented yet.

Actually you need to add every information you need to determine the correct resource into the resource path, thus it somehow is a REST url. I also added a resource-version to the path in order to deal with resource-update-browser-cache problems.

Regards,
Jakob

Comment by Ed Burns [ 27/Feb/12 ]

Jakob, can you please hack upon this sample war to make it show the problem? The current war does use relative resources, but the browser is able to resolve them. Can you make it so the browser cannot resolve them?

Comment by Jakob Korherr [ 29/Feb/12 ]

Hi Ed,

Your sample is somehow funny. You use a css file in webapp/resources/library/style.css using relative paths like this: url(../../included.css) and url(../../expert-draft-bg.png). The two referenced resources, of course, are located two folders up in the directory tree (directly in webapp).

Now as it would seem to be logical that this works, it really is a coincidence. You see, style.css is loaded via the following url:

http://localhost:8080/faces/javax.faces.resource/style.css?ln=library

Thus, included.css and expert-draft-bg.png are loaded by the browser using the following urls:

http://localhost:8080/included.css
http://localhost:8080/expert-draft-bg.png

The 1st ".." removed "javax.faces.resource" and the 2nd ".." removed "faces" (however, you would actually think that the 1st ".." removes library and the 2nd ".." removes "resources"). This, of course, only works because tomcat (or any other servlet container) serves the two files directly, and it has nothing to do with the JSF resource handler (e.g. ValueExpressions won't work!).

Now, there are a number of possibilities to break the example:
1) use .jsf instead of /faces/ FacesServlet mapping
2) locate the two resources in the same folder as style.css (while removing the ".." sequences in style.css)
3) locate the two resources in the classpath (META-INF/resources)
...

I used the 2nd of the above options in my sample_broken.zip.

Here, style.css still gets loaded via:

http://localhost:8080/faces/javax.faces.resource/style.css?ln=library

But now the browser tries to locate included.css and expert-draft-bg.png using these urls:

http://localhost:8080/faces/javax.faces.resource/included.css
http://localhost:8080/faces/javax.faces.resource/expert-draft-bg.png

Which does NOT work, because the library request parameter is missing. My approach (http://code.google.com/a/apache-extras.org/p/relative-resource-handler/) creates an url in which the library is included in the url path, thus this will work.

If you have any further questions, please ask!

Regards,
Jakob

Comment by Jakob Korherr [ 29/Feb/12 ]

Added sample_broken.zip

Comment by Ed Burns [ 29/Feb/12 ]

Thanks for demonstrating to me exactly how this is broken.

Now I can proceed to better see how to fix it!

Comment by Ed Burns [ 29/Feb/12 ]

Looking at your relative-resource handler, it is immediately apparent that the ability for the relative resources to even work is based on how you are encoding the library name differently from what is specified. As stated in the javadocs for RelativeResourceHandler, you have to use

META-INF/relative-resources.xml

to declare libraries and we can't accept that requirement in the spec. Also, the stated limitation of only being able to work with prefix mapped JSF runtimes is unacceptable.

I can see why you made these decisions and how they enable the nice features of your Relative ResourceHandler, but we need to figure out how to do what you request without making unacceptable compromises.

Comment by Ed Burns [ 29/Feb/12 ]

Jakob, what is the main reason for being dissatisfied with this syntax for relative resources?

css_master.css:

@import url(#

{resource['this:layout.css']}

);

Is it performance?

Comment by Jakob Korherr [ 29/Feb/12 ]

The need to have the libraryName configured in relative-resources.xml does only exist, because I needed a way to enable the RelativeResourceHandler only for certain libraries. This would not be necessary if the standard ResourceHandler already uses the "relative-mechanism" (for all libraries).

There are many reasons:

1) Acceptance: There is no other framework (at least which I know of), in which you cannot use relative paths between resources as they would work in the file system. Nearly every IDE supports "resource-exists-checks" in css files with relative paths in the file system, and these IDEs will mark #

{resource[]}

url references as errors. Every server (http or servlet container), CDN,... supports relative paths in the URLs like a normal file system, why should JSF do this differently?

2) Effort: You need quite a lot of time to change a big CSS framework (which you will get from your designers) into a working JSF version. And remember, next day the designer may change something, then you will get a new version of the whole CSS framework, and the work starts again...

3) Performance: Actually, having ValueExpressions in resource files is not only a performance killer, it also gives the developer the impression as if she could change resource file contents in every request, whereas she really cannot, because the resource will get cached by the browser/proxy.

I actually would not use the current JSF ResourceHandler because of these points and instead let tomcat (or even weblets) handle my resources, because they both support relative paths like a calm.

Comment by Ed Burns [ 20/Mar/12 ]

A resource path from Jakob's impl looks like
"/javax.faces.resource/1.0.0/en_US/css/style.css". Does that 1.0.0
refer to library version or resource version?

Here's a clue, from RelativeResourceHandler#132.

// skip version in url (first part, only there to avoid cache problems on updates)
final int versionSlash = resourceName.indexOf('/');

But that still doesn't answer my question. What does the 1.0.0 mean?

Jakob's ResourceHandler.createResource() allows the entire resourceId to
be in the "resourceName", which it re-interprets according to its own
rules if it determines that the library is not a JSF 2.0 style resource
library.

JK> The need to have the libraryName configured in
JK> relative-resources.xml does only exist, because I needed a way to
JK> enable the RelativeResourceHandler only for certain libraries. This
JK> would not be necessary if the standard ResourceHandler already uses
JK> the "relative-mechanism" (for all libraries).

Ok, let's say we make relative libraries the default for prefix mapped
applications. If we have a jar in the classpath that contains a library
that is arranged according to the JSF 2.0 spec for resource libraries,
we now we need some way to detect that case and use the JSF 2.0 style
arrangement, right?

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-559] Support for the "Synchronizer Token" pattern (avoiding double submits) Created: 05/May/09  Updated: 11/Sep/15

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

Type: New Feature Priority: Critical
Reporter: kito75 Assignee: kito75
Resolution: Unresolved Votes: 13
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File jsf2csrf.war     File jsf2token.war    
Issuezilla Id: 559
Status Whiteboard:

cat2 frame size_medium importance_large cat3 draft


 Description   

This is a very common web application problem
(http://www.javajunkies.org/index.pl?lastnode_id=3361&node_id=3355) – avoiding
double submits. Struts had built-in support for this. JSF-related implementations:

Spring Web Flow, Struts 2, and Grails 1.1
(http://www.grails.org/1.1+Release+Notes) also support this natively.

I'd really like to see this in JSF 2.1 at the very latest.



 Comments   
Comment by Ed Burns [ 11/Aug/09 ]

Move to 2.1. Also make this handle Dan's concern here:

DA> It's crucial that the enablement of this feature be accompanied by a
DA> secure token being exchanged in the case of server-side state
DA> saving.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

lifecycle

Comment by Ed Burns [ 07/May/10 ]

Transaction token has been requested many times over the years.

Comment by kito75 [ 08/May/10 ]

I've got some code I wrote for a client based on Shale's token that I can clean up and submit as a
prototype. If you're interested, just let me know when it's time.

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

xsrf

Security related, target for GlassFish 3.1 M3

Comment by Ed Burns [ 30/Jun/10 ]

cat3

Comment by rogerk [ 01/Jul/10 ]

Hey Kito -

It's time. Let's see what you have. If you can also submit a proposal that
would be helpful as well.

-roger

Comment by rogerk [ 01/Jul/10 ]

This could probably reside in the core namespace - like f:token ?

Comment by Ed Burns [ 01/Jul/10 ]

Roger, please take a look at https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=812 for more
valuable information.

Comment by rogerk [ 01/Jul/10 ]

Ahh yes - thanks for the pointer. Apparently there are many ways to skin this
cat ....

Comment by kito75 [ 14/Jul/10 ]

Created an attachment (id=255)
Sample CSRF Solution (JSF 1.2)

Comment by kito75 [ 14/Jul/10 ]

Created an attachment (id=256)
Sample CSRF Solution (JSF 1.2) – the other file is for avoiding double submits

Comment by kito75 [ 14/Jul/10 ]

I have attached two samples:

  • jsf2token.war – sample UIToken component specifically for avoiding double submits (but would
    probably handle CSRF attacks too)
  • jsf2csrf.war – sample solution for handing Cross-site Request Forgery (CSRF) attacks only.

The source for both is in the WEB-INF/classes directory.

The token approach uses a standard JSF component that outputs a hidden field in the form. The hidden
field is created based on a server-generated secret key plus other information, such as the current view
id. What's a little different is that a phase listener decodes the component before Apply Request Values.
The goal here was to check the token before any other decoding takes place. Also, the token isn't
released until after Invoke Application to ensure that application processing has occurred.

For JSF 2, I think either enhancing UIForm, providing an alternate UIForm, or using a ClientBehavior
might be a better option than a separate component. Using UIForm would avoid the need to handle
decoding in the PhaseListener.

The CSRF approach is a little different. It still generates a special token based on a server-generated
secret key, but it does so based on the session, not on the view. It then appends the token to every JSF-
generated request through ViewHandler.getActionURL(). It uses a PhaseListener to ensure that every
incoming request has a valid token.

It's possible to combine these approaches, but I like the way the CSRF approach doesn't require anything
on the part of the developer. The caveat is that since it's session-based, it's probably not secure as a
form-based approach. Also, a form-based variant is required to avoid double-submits.

I'm not familiar with back button solutions, so I can't comment on how this code is applicable.

Comment by kito75 [ 14/Jul/10 ]

We should also consider the Seam <s:token> approach
(http://seamframework.org/Community/NewComponentTagStokenAimedToGuardAgainstCSRF). This is
component-based approach by Dan Allen with two key artifacts:

This approach also uses a cookie to ensure the requests are coming from the same browser, which is a
nice feature (but it should be optional). It also has explicit support for client-side state saving, which
my solution does not.

Comment by rogerk [ 22/Jul/10 ]

re-target

Comment by rogerk [ 23/Jul/10 ]

I've created a separate spec issue for CSRF:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869
as it solves a different problem.

Comment by rogerk [ 13/Aug/10 ]

target

Comment by rogerk [ 13/Aug/10 ]

Starting

Comment by rogerk [ 27/Aug/10 ]

reset priority

Comment by rogerk [ 13/Sep/10 ]

target 2.2

Comment by joshbrookes [ 18/May/11 ]

This issue has remained untouched since mid-Sept of 2010. Is this still being targeted for development or is there a recommended 3rd-party utility that can be used with Mojarra?

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by codylerum [ 23/Mar/15 ]

While Seam is out of date, https://deltaspike.apache.org/documentation/jsf.html#_double_submit_prevention is a more current solution.

Inclusion into 2.3 would be a huge help to a common problem.

Comment by Manfred Riem [ 06/Aug/15 ]

Kito, can you take charge of this issue and look for an implementation strategy? Thanks!

Comment by kito75 [ 10/Aug/15 ]

Sure, I can.

Comment by gerhard_petracek [ 11/Sep/15 ]

fyi:
DeltaSpike keeps the valid token in a window-scoped bean -> there is only one known token per window/tab -> there is no impact on the state of the component tree and it isn't possible to "reactivate" a previous key -> ds:preventDoubleSubmit just renders the current key.





Relative Resources (JAVASERVERFACES_SPEC_PUBLIC-947)

[JAVASERVERFACES_SPEC_PUBLIC-884] Support library prefix in resource URLs Created: 17/Sep/10  Updated: 09/Sep/15

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.0
Fix Version/s: None

Type: Sub-task Priority: Critical
Reporter: cayhorstmann Assignee: Ed Burns
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Duplicate
duplicates JAVASERVERFACES_SPEC_PUBLIC-947 Relative Resources Open
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900 Images resources in css with relative... Closed
Issuezilla Id: 884
Status Whiteboard:

size_small importance_medium


 Description   

Consider a stylesheet

<h:outputStylesheet library="styles" name="skin.css"/>

Resources are loaded with URLs such as

/context path/faces/javax.faces.resource/skin.css?ln=styles

(when prefix mapping is used).

CSS files commonly contain url(...) expressions such as

.ui-icon

{ width: 16px; height: 16px; background-image: url(myicon.png); }

These url(...) expressions fail to locate the dependent resources.

This discussion further explains the problem:
http://forums.sun.com/thread.jspa?threadID=5447194.

It is not reasonable to ask the users to rewrite the URLs in the style sheet
since style sheets are often auto-generated.

While it might be possible for JSF to automatically rewrite the URLs in a style
sheet as it is loaded, that would not work for other files (e.g. JavaScript).

If instead the library name is added as a prefix, then the problem goes away:

/context path/faces/javax.faces.resource/styles/skin.css

(NB. I believe the ?ln=xxx is a vestige of an earlier time
when the version and resource prefix were also specified as request
parameters, see
http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature.)

In the interest of backward compatibility, we can to provide an application
configuration parameter

javax.faces.RESOURCE_URL_MAPPING with options prefix and param

Then
http://download-llnw.oracle.com/javaee/6/api/javax/faces/application/Resource.html#getRequestPath%28%29
needs to be changed as follows:

  1. If getLibraryName() returns non-null, discover if the resources are prefix or
    param mapped, by consulting the application configuration parameter
    javax.faces.RESOURCE_URL_MAPPING. If prefix mapped, insert "/" +
    getLibraryName() after ResourceHandler#RESOURCE_IDENTIFIER. If param mapped, ...


 Comments   
Comment by Ed Burns [ 26/Oct/10 ]

2.2

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by ramiromagalhaes [ 14/Apr/11 ]

This is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900.

Comment by lamine_ba [ 14/Apr/11 ]

It seems that someone has reported this issue since a long time . It was one of the first issue I have to deal with JSF 2.0. How to load with css an image stored in my images folder?
If my faces servlet is mapped to .faces, I can overcome this problem by doing this

background-image: url(myicon.png.faces?ln=images)

If my faces servlet is mapped to /faces/*, I can overcome this problem by doing this

background-image: url(myicon.png?ln=images)

If would be nice if we could come back to this

background-image: url(images/myicon.png)

Comment by Jakob Korherr [ 15/Apr/11 ]

The problem described by lamine_ba is exactly why I created the MyFaces commons resourcehandler module (see [1]). Fortunately I already talked with Ed about it, and we will try to address this issue by re-using some of the code/concepts from MyFaces commons resourcehandler!

[1] https://svn.apache.org/repos/asf/myfaces/commons/branches/jsf_20/myfaces-commons-resourcehandler/

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.





[JAVASERVERFACES_SPEC_PUBLIC-1315] Simplify EL resolver chain by using CDI Created: 08/Oct/14  Updated: 20/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: EL
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Manfred Riem Assignee: arjan tijms
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Zip Archive newfiles.zip    
Issue Links:
Blocks
is blocked by JAVASERVERFACES-3478 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1386 Let CDI handle #{flowScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1387 Let CDI handle #{header} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1388 Let CDI handle #{headerValues} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1389 Let CDI handle #{initParam} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1390 Let CDI handle #{param} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1391 Let CDI handle #{paramValues} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1392 Let CDI handle #{request} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1393 Let CDI handle #{requestScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1394 Let CDI handle #{resource} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1311 Let CDI handle #{facesContext} EL res... Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1322 Simplify #{externalContext} to use Ex... Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1325 Let CDI handle #{applicationScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1328 Let CDI handle #{session} EL resolving Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1331 Let CDI handle #{application} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1332 Let CDI handle #{view} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1334 Let CDI handle #{viewScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1383 Let CDI handle #{cc} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1384 Let CDI handle #{component} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1385 Let CDI handle #{flash} Resolved
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open

 Comments   
Comment by Manfred Riem [ 15/Oct/14 ]

Make sure the appropriate spec text is added for:

application - describe that this only does EL resolving
applicationScope
externalContext
facesContext
session - describe that this only does EL resolving (core CDI does the @Inject for session)
view
viewScope

Comment by arjan tijms [ 30/Jul/15 ]

This is the current overview of the EL implicit variables handled by CDI:

* application
*+ applicationScope (applicationMap)
cc
component
+ cookie (requestCookieMap)
*+? externalContext
*+ facesContext
flash
flowScope
header
headerValues
initParam
param
paramValues
request
requestScope
resource
* session
+ sessionScope (sessionMap)
*+ view (view root)
*+ viewScope (viewMap)

* = Implemented via issue 1315 (this issue)
+ = Implemented via issue 1316
? = new implicit EL variable

Preliminary implementation of entries not yet committed in the 2.3 trunk: https://github.com/omnifaces/mojarra/commit/1fa3ad6f0919eedc613cf21d4390a9d20c80e39c

Comment by Manfred Riem [ 20/Aug/15 ]

r=mriem

Comment by arjan tijms [ 20/Aug/15 ]

Applied to 2.3 trunk:

svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1315, moved qualifiers to new annotation package. r=mriem"
Adding jsf-api/src/main/java/javax/faces/annotation
Adding jsf-api/src/main/java/javax/faces/annotation/ApplicationMap.java
Adding jsf-api/src/main/java/javax/faces/annotation/RequestCookieMap.java
Adding jsf-api/src/main/java/javax/faces/annotation/SessionMap.java
Adding jsf-api/src/main/java/javax/faces/annotation/ViewMap.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/ApplicationMapAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/RequestCookieMapAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/SessionMapAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/ViewMapAnnotationLiteral.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectApplicationMap2Bean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectApplicationMapBean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectRequestCookieMap2Bean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectRequestCookieMapBean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectSessionMap2Bean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectSessionMapBean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectViewMap2Bean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectViewMapBean.java
Transmitting file data ................
Committed revision 15029.





[JAVASERVERFACES_SPEC_PUBLIC-1298] Resolve backward incompatible change regarding PartialResponseWriter.writePreamble() Created: 11/Aug/14  Updated: 10/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3366 Fix ResponseWriter backwards compatib... Closed

 Description   

Issue JAVASERVERFACES_SPEC_PUBLIC-1069 was introduced to cover a problem with jsf.js and Portets. Unfortunately, the resolution was backward incompatible for parties that implement ResponseWriter.



 Comments   
Comment by Ed Burns [ 11/Aug/14 ]

These were done at the request of the portlet community:

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1069

And in fact Blake did weigh in on this way back then:

https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-02/message/49

B> I guess I would question whether any fixes for 1) or 2) are
B> necessary. The proposal before is to make non-backwards compatible
B> behavior changes. For such a change, I would want to see some clear
B> benefits. In this case, the Bridge has a work-around. It doesn't
B> sound like the work-around is hurting performance--nor does it sound
B> like the Bridge is being asked to do something outside of its
B> purview--which in this case is turning a document-oriented page into
B> a fragment.

And Neil Griffin replied with a justification:

https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-02/message/57

But there the discussion appears to have ended. It looks like we ended
up going with Neil's suggestions.

Comment by Ed Burns [ 11/Aug/14 ]

Let me clarify why Blake asserts this is a backward incompatible change.

In JSF 2.1, the writing of the XML preamble was the responsibility of the PartialResponseWriter.startDocument().

In JSF 2.2, we moved that out into PartialResponseWriter.writePreamble(), removing it from PartialResponseWriter.startDocument(). This means that any code that was counting on the XML preamble having been written based on a JSF 2.1 runtime will fail when running against a JSF 2.2 runtime.

Comment by btsulliv [ 14/Aug/14 ]

To clarify further, this change was guaranteed to be incompatible because all pre-2.2 code had to rely on startDocument() writing any necessary XML declaration or docType as the new methods:

writePreamble

public void writePreamble(String preamble)
throws IOException
Write a string containing the markup specific preamble. No escaping is performed. The default implementation simply calls through to Writer.write(java.lang.String) .

The implementation makes no checks if this is the correct place in the response to have a preamble, nor does it prevent the preamble from being written more than once.

Parameters:
preamble - Text content of the preamble
Throws:
IOException - if an input/output error occurs
Since:
2.2
writeDoctype

public void writeDoctype(String doctype)
throws IOException
Write a string containing the markup specific doctype. No escaping is performed. The default implementation simply calls through to Writer.write(java.lang.String) .

The implementation makes no checks if this is the correct place in the response to have a doctype, nor does it prevent the doctype from being written more than once.

Parameters:
doctype - Text content of the doctype
Throws:
IOException - if an input/output error occurs
Since:
2.2

Did not exist before 2.2 and therefore could never have been called. This reason should have been sufficient on its own to have precluded the current design as minor releases are not allowed to break compatibility and even major releases should have a could have a good reason for doing so. In this cases, even the justification was sorely lacking:

"For JSF 2.2 portlet alignment, I think it's important (from a design perspective) to fix servlet environment assumptions in the JSF API or Spec. If such assumptions are present in a JSF implementation, then the portlet bridge can simply perform overrides at the proper extension points. The solutions below seem reasonable to me, since they appear to be implementation details that do not affect existing JSF applications."

It should be pointed out that:
1) The rationale is incorrect--the problem in this case wasn't that the JSF ResponseWriter was servlet-oriented, but rather, that the ResponseWriter assumed that startDocument() would actually begin writing a new document. In the Portlet case, the bridge wanted to write its own envelope content and then embed the payload from the wrapped writer inside this content. When the envelope was XML, the XML declaration and doctype caused problems.

2) The bridge had already worked around this problem by parsing the beginning of the wrapped content and discarding the XML declaration and docType. Since this content was at the beginning of the output of the wrapped content, this was actually pretty fast. The advantage of the change was that it made this aspect of the Portlet bridge easier to re-implement and faster (though this part isn't performance critical).

To make this worse, the rest of the design was messed up:

1) the two new methods should never have been public as an application calling these methods can only cause harm. This is because
a) In order to pass the correct parameters, the application would have to know the implementation of the ResponseWriter
b) If the application passes different parameters than the ResponseWriter expects, bad things can happen

The point of adding these methods as hooks for a ResponseWriter implementation could have been met with protected methods, thus avoiding potential new sources of error.

These problems are compounded by the lack of documentation surrounding the new contract in the javadoc for the class.

While it is clear that we should have never added these methods in the first place, let alone in the current fashion, we are stuck with trying to make these work the best we can. To that end we have two approaches:

Simple:

Admit that this was a bad idea. Make the new methods no-ops, go back to the old behavior and put the portlet bridge code back as well. This is by far the smallest change.

Change the incompatibility from the callers of the ResponseWriters (application developers) to the ResponseWriter implementations. This is actually less compatible than making the apis no-ops.

1) Document that while writeDocType and writePreamble are public, they should only be called by ResponseWriter implementations. Application developers should continue to only call startDocument
2) Document that neither writeDocType not writePreamble should be called after startDocument, that writePreamble should preceed any call to writeDocType and implementations are allowed, but not required to throw an IllegalStateException if this occurs.
3) Require that ResponseWriter implementations call writePreamble if writeDocType is called without a preceeding call to writePreamble and both
a) This ResponseWriter supports docTypes
b) This ResponseWriter supports a preamble
4) Require that ResponseWriter implementations call writeDocType if startDocument is called without a preceeding call to writeDocType (which will then cause the correct preamble to be written, if necessary)
5) Allow the ResponseWriter to throw IllegalArgumentExceptions if the parameters passed to writePreamble or writeDocument

This is still an incompatible change for ResponseWriter implementors, who now need to maintain state. Note that if we had made the new methods protected and simply requried that the ResponseWriter implementations call these methods from startDocument, the change would have still been incompatible (as we are placing a new requriement on ResponseWriter implemetors), but much simpler overall, as the expectations for subclassers calling things correctly are less sever than for application developers.

Comment by Ed Burns [ 05/Sep/14 ]

This is still an incompatible change for ResponseWriter implementors, who now need to maintain state. Note that if we had made the new methods protected and simply requried that the ResponseWriter implementations call these methods from startDocument, the change would have still been incompatible (as we are placing a new requriement on ResponseWriter implemetors), but much simpler overall, as the expectations for subclassers calling things correctly are less sever than for application developers.

Looking at the Java EE compatibility guidelines < https://java.net/projects/javaee-spec/pages/CompatibilityRequirements >, I don't see anything that forbids making formerly public methods protected. Blake, if we were to do this and required your steps 1) and 2) above, would that be sufficient?





[JAVASERVERFACES_SPEC_PUBLIC-1380] Utilize @FacesDataModel for existing DataModel wrappers Created: 19/Jul/15  Updated: 10/Sep/15

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

Type: New Feature Priority: Critical
Reporter: arjan tijms Assignee: arjan tijms
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1078 Have DataModel implementations regist... Reopened

 Description   

JAVASERVERFACES_SPEC_PUBLIC-1078 introduced a mechanism to register and lookup DataModel wrappers for (collection) types.

The components UIData and UIRepeat only utilize this mechanism as a "last resort". Meaning that a type that needs wrapping is first checked against a chain of types for which build-in wrappers are available. Only if none of these match is the @FacesDataModel mechanism consulted.

To have a more consistent model and most importantly allow overrides of build-in wrappers @FacesDataModel should always be consulted and there should be no build-in wrappers anymore.

Since this has backwards compatibility consequences, the best course of action may be to put this new behavior behind a switch and retain the old behavior as well.






[JAVASERVERFACES_SPEC_PUBLIC-1342] Support @Inject of current flow like "@Inject Flow currentFlow" Created: 12/Dec/14  Updated: 10/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: arjan tijms
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

CDI Conversation scope is injectable into @ConversationScoped beans like this:

@Inject
Conversation currentConversation

The same should be true for the current Flow for @FlowScoped beans.






[JAVASERVERFACES_SPEC_PUBLIC-1360] Address corner cases as a result of issue #1127 Created: 03/Feb/15  Updated: 26/Aug/15

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

Type: Bug Priority: Critical
Reporter: Manfred Riem Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The issue here is that the optimization intended by 1127 cannot be guaranteed in light of two important cases.

case_Ajax

Multiple rapid Ajax submits cause the view tree to be shared across multiple concurrent requests.

case_MultiSubmit

Multiple rapid non-Ajax submits cause the view tree to be shared across multiple concurrent requests.






[JAVASERVERFACES_SPEC_PUBLIC-1359] Resolve views from dedicated folder Created: 02/Feb/15  Updated: 21/Aug/15

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

Type: New Feature Priority: Critical
Reporter: arjan tijms Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1099 Resolve views by convention from dedi... Closed
is related to JAVASERVERFACES-3791 Implement JAVASERVERFACES_SPEC_PUBLIC... Open

 Description   

The Facelets VDL will by default try to resolve a view in the root of a web application or in META-INF/resources of a jar file (where the jar location automatically follows from using ServletContext#getResource)

In addition to this primary location I would like to propose loading views from a dedicated folder called "/views". This should be done in analogy to how contracts are loaded from "/contracts" and resources from "/resources", including the ability to let a user configure an alternative location.

The use case for this is letting the user easily configure a simple alternative location from where views are loaded and opening up more advanced processing by the runtime.

This more advanced processing is not part of this issue. This issue is strictly about providing a folder from which views (and only views) can be loaded.

Note that this issue is split-off from JAVASERVERFACES_SPEC_PUBLIC-1099, which asked about this folder but also asked about the advanced processing.



 Comments   
Comment by arjan tijms [ 03/Feb/15 ]

Sort of sub-issue of 1099





[JAVASERVERFACES_SPEC_PUBLIC-1348] Better define usage of Flash, specifically with respect to response buffer size Created: 12/Jan/15  Updated: 12/Jan/15

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

Type: Improvement Priority: Critical
Reporter: Manfred Riem Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1320 Expose Flash for use from MVC Closed




[JAVASERVERFACES_SPEC_PUBLIC-1265] Clarify that a piece of text in the navigation handler section of the spec only pertains when inside of a flow. Created: 07/Feb/14  Updated: 04/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3130 NavigationHandlerImpl differs from sp... Closed

 Description   

Consider this spec text, from section 7.4.2:

If the <to-view-id> element is a non-view flow node, resolve it to a vdl view identifier by following the algorithm in Section 7.4.2.1 "Requirements for Explicit Navigation in Faces Flow Call Nodes other than ViewNodes".

That text only pertains to navigation within a flow. This restriction must be explicitly called out.



 Comments   
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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1244] Reword requirements for EL expressions inlined in Facelets pages, but outside of components. Created: 19/Dec/13  Updated: 10/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days


 Description   

Text copied from JAVASERVERFACES-3094

The JSF spec (2.1) requires in section 10.3.1 that "The runtime must ensure that EL expressions that appear in the page without being the right-hand-side of a tag attribute
are treated as if they appeared on the right-hand-side of the value attribute of an <h:outputText /> element in the http://java.sun.com/jsf/html namespace." This should also work in this case.

This text is problematic with respect to c:set and friends.

I suggest we soften the above language to make it clear that we don't need to have UIOutput instances in the tree. Rather, we just need it to render as if we did.



 Comments   
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.





[JAVASERVERFACES_SPEC_PUBLIC-1185] Pass Through attribute should have priority when rendering Created: 25/Apr/13  Updated: 19/Aug/15

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

Type: Bug Priority: Critical
Reporter: Bruno Borges Assignee: Ed Burns
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1270 JavaDoc for TagDecorator regarding pa... Resolved

 Description   

Tried the following code:

index.xhtml
<a href="anotherPage_fake.xhtml" jsf:outcome="/anotherPage.xhtml">Another Page</a>

The href attribute rendered contains the value anotherPage_fake.xhtml. In this case (and similar others), the pass through attribute should have priority in the rendering process, if it will compete with a static attribute.



 Comments   
Comment by Bruno Borges [ 13/Aug/13 ]

Digging more into Pass Through Attributes, I find this feature one of the best things I've ever seen in JSF in years, because it could bring development/designer preview without the need to run an app server. A feature that several frameworks permit, such as Apache Wicket and Tapestry. But if Pass Through Attributes doesn't override regular attributes, then it becomes not interesting.

The spec is not clear about this, and I think it should be provided an Errata, with a change in the current implementation.

Sample A

 
<script type="text/javascript"
             src="../../js/jQuery.js"
             p:src="${facesContext.externalContext.requestContextPath}/js/jQuery.js"></script>

Sample B

<script type="text/javascript" src="../../js/jQuery.js">
    <f:passThroughAttribute
       name="src"
       value="${facesContext.externalContext.requestContextPath}/js/jQuery.js" />
</script>

Either samples should end up with this:

<script type="text/javascript" src="/myapp-1.0-SNAPSHOT/js/jQuery.js"></script>
Comment by Frank Caputo [ 13/Aug/13 ]

Pass through attributes have priority as specified in the “Rendering Pass Through Attributes” section of the overview of the standard HTML_BASIC render kit: https://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/renderkit-summary.html#general_behavior_encoding

In <a href="anotherPage_fake.xhtml" jsf:outcome="/anotherPage.xhtml">Another Page</a> the href attribute becomes a pass through attribute and thus has priority.

Comment by Bruno Borges [ 13/Aug/13 ]

Hi Frank, thanks for pointing that out, but I disagree that "static" attributes should have priority when faced against calculated/dynamic attributes such as jsf:outcome.

If an element has both attributes (a static like 'href', and a dynamic as 'jsf:outcome'), the general idea is that the static attribute is for static preview/prototyping only, and should be replaced by the calculated value.

This is how other web frameworks have been doing for years.

Comment by jyeary [ 13/Aug/13 ]

The link you specified has some very specific text about priority.

The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence. Pass through attributes are rendered as if they were passed to ResponseWriter.writeURIAttribute().

Unless I am reading this incorrectly, the jsf:outcome should take precedence over the static href attribute. I am on the fence on this though. I think that the pass through attributes are a great addition to the framework. However, if the renderer has the attribute defined, it can be set dynamically using EL. In this case, pass through attributes are simply duplicating the renderer specific attributes. This is for the case of the JSF components.

What advantages do we gain from the pass through taking precedence over the renderer specific attributes if they duplicate each other? I would say that the renderer specific attributes should take precedence.

In the case of static HTML template text (UIInstructions) , it makes sense that the dynamic pass through should take precedence over the static attribute such as href.

Comment by Bruno Borges [ 13/Aug/13 ]

In the case of static HTML template text (UIInstructions) , it makes sense that the dynamic pass through should take precedence over the static attribute such as href.

This is what I'm looking for. I don't want to loose the "previability" of the page.

Comment by Ed Burns [ 28/Aug/13 ]

From the spec section cited by John and Frank:

The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence.

Consider Bruno's original markup:

<a href="anotherPage_fake.xhtml" 
   jsf:outcome="/anotherPage.xhtml">Another Page</a>

Because this is an <a> element with a jsf:outcome attribute, it is treated as an h:link, specified in the following.

http://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Link.html

Perhaps the root problem here is that there is another set of attributes that must be considered, separate from the set of renderer specific attributes. This is the set of attributes that the renderer itself must use when rendering the component. Let's call these renderer required attributes. I suggest that the spec be modified to define the term renderer required attributes, and to say that renderer required attributes take precedence over pass through attributes on the markup.

Unfortunately, there is no runtime representation of the set of renderer required attributes, so it's not possible for the spec to say that, though. We would need to have a way for each renderer to declare its set of renderer required attributes, then we could require the ResponseWriter to act accordingly based on the priority.

There is no conflict because "href" is not a renderer specific attribute.

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1202] cc:attributes type attribute: fallback case: use what the ELResolver returns. Created: 03/Jul/13  Updated: 10/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours


 Description   

JAVASERVERFACES_SPEC_PUBLIC-745 amended the language for the Composite Component Attributes ELResolver's getType() method.

An additional change is needed for correctness to the cc:attribute tag's type attribute. The existing language states:

Declares that this attribute must be a ValueExpression whose expected type is given by the value of this attribute. If not specified, and no "method-signature" attribute is present, java.lang.Object is assumed. This attribute is mutually exclusive with the "method-signature" attribute. If both attributes are present, the "method-signature" attribute is ignored.

This needs to be changed. Instead of assuming java.lang.Object, the system must use the return from the CC attribute ELResolver's getType() method.



 Comments   
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.





[JAVASERVERFACES_SPEC_PUBLIC-49] JS function for "give me the clientId" Created: 04/Oct/04  Updated: 26/Jan/15

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

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: cagatay_civici
Resolution: Unresolved Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: Text File changebundle.txt    
Issuezilla Id: 49
Status Whiteboard:

EGTop5 effort_hard cat2 jsdoc size_medium importance_small draft


 Description   

EB> R1 something you can stick in your page, that will evaluate to the full,
EB> absolute, clientId of the named thing when the page is rendered. Like
EB> this:

AVK> <h:button id="button1"
AVK> onclick="button_setEnabled(button2,
AVK> false);button_clicked(button1);return"
AVK> ... />
AVK> <h:button id="button2" ... " />

AVK> then I want the result of the first one to be

AVK> <input type="submit" id="myform:button1"
AVK> onclick="button_setEnabled('myform:button2', false);
AVK> button_clicked('myform:button1'); return;"
AVK> ... />

EB> R2 This thing can be presenent in an attribute value, or as template
EB> text.

AVK> Definitely needed in an attribute value, for the method invocation. I
AVK> don't know whether it is necessary in tempate text. I have a feeling
AVK> some JavaScript interpreters barf if you mention the id before the
AVK> element is present.

EB> R3 This thing must only work within the scope of a naming
EB> container. In other words, I can't use this mechanism to refer
EB> to something in form B if I'm inside Form A.

EB> R4 This thing must work in a multi-include page scenario

EB> R5 This thing must work in a portlet scenario



 Comments   
Comment by Ed Burns [ 23/Feb/05 ]

push to 2.0

Comment by Ed Burns [ 09/Sep/08 ]

EGTop5

Comment by Ed Burns [ 12/Sep/08 ]

effort_hard

Comment by Ed Burns [ 21/Oct/08 ]
      • Issue 293 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 21/Oct/08 ]

Change summary

Comment by Ed Burns [ 06/Nov/08 ]

Given the #

{component}

and #

{compositeComponent}

implicit objects, and the ability to use them on the
server side, in XHTML, and in resources, having the ability to say #

{component.clientId}

would be nice. To
do this, we need to add to UIComponent, String getClientId(). This just does
FacesContext.getCurrentInstance() and calls the other getClientId().

Comment by Ed Burns [ 06/Nov/08 ]

Created an attachment (id=163)
Fix for this bug, first iteration.

Comment by Ed Burns [ 28/Jul/09 ]

Push out to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

jsdoc

Comment by Ed Burns [ 27/Apr/10 ]

no sig change

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

target

Comment by Ed Burns [ 04/Feb/12 ]

Remove from consideration for 2.2

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting to Critical, verify if it is already done or not.





[JAVASERVERFACES_SPEC_PUBLIC-1150] Add @ClientWindowScoped Created: 04/Dec/12  Updated: 05/Oct/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Managed Beans
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JSF 2.2 added ClientWindow capabality. There should be a corresponding CDI scope.



 Comments   
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.

Comment by frederickkaempfer [ 05/Oct/15 ]

Please note the importance of specifying client window timeouts and/or a maximum number of client windows per http session to provide an upper limit of the memory requirements of this feature. Faces Flows currently do not have such a limit either (https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1398), but could get it as well by storing them in the client window scope.





[JAVASERVERFACES_SPEC_PUBLIC-1414] f:validateWholeBean should allow the user to select the copy strategy (a copier attribute) Created: 12/Feb/16  Updated: 12/Feb/16

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

Type: Improvement Priority: Critical
Reporter: anghelleonard Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Payara 4.1






[JAVASERVERFACES_SPEC_PUBLIC-790] javax.faces.ViewState + PPR does not work out for cross form ppr cases Created: 06/May/10  Updated: 27/Jul/16

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Bug Priority: Critical
Reporter: werpu12 Assignee: balusc
Resolution: Unresolved Votes: 59
Labels: None
Remaining Estimate: 5 days
Time Spent: Not Specified
Original Estimate: 5 days
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File 790-js-workaround.txt     Text File changebundle.txt     Text File changebundle.txt     Java Source File ExtendedViewHandler.java    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-3436 ViewScoped bean reconstructs when usi... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1093 The id attribute of javax.faces.ViewS... Open
is related to JAVASERVERFACES-1715 Missing ViewState during partial view... Closed
Issuezilla Id: 790
Status Whiteboard:

size_small importance_small


 Description   

Following problem

<h:form id="a">
    <h:commandButton action="#{TestBean.action}" value="submit"/>
</h:form>

<h:form id="b">
    <h:commandLink value="ajax ReRender" 
        onclick="jsf.ajax.request(this,event,{execute:'b a',render:'a'}); return false;"/>
</h:form> 

Cannot work out because, the viewstate is returned as separate viewstate block
(in both implementations the <update id="a"> does not pass the viewState in the
update block).

Now the specification says:

If an update element is found in the response with the identifier
javax.faces.ViewState:

<update id="javax.faces.ViewState">
   <![CDATA[...]]>
</update>

locate and update the submitting form's javax.faces.ViewState value with the
CDATA contents from the response.

Which means in this special case that the viewState for form a is lost.
Mojarra has fixed this to some degree by setting the viewstate if a direct form
render on a happens.

However if you do following:

<h:panelGroup id="myGroup">
    <h:form id="a">
        <h:commandButton action="#{TestBean.action}" value="submit"/>
    </h:form>
</h:panelGroup>

<h:form id="b">
    <h:commandLink value="ajax ReRender" 
        onclick="jsf.ajax.request(this,event,{execute:'b a',render:'myGroup'}); return false;"/>
</h:form> 

Mojarra also fails.

The problem here lies clearly with the spec, I am not sure why the viewstate is
only updated to the issuing form.

Either all forms must be updated or at least the forms which are processed both
within the execute and render parts.

I also opened a discussion on the open mailing list regarding this, since this is
a usecase which can happen quite often in a typical rich client scenario where a
lot of detachments can happen to satisfy ie6 and multiple forms are the norm if
you have floating frames.



 Comments   
Comment by Ed Burns [ 24/May/10 ]

Agree for inclusion in 2.0 Rev a

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 27/May/10 ]

I agree we should update all forms. Move to 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by werpu12 [ 12/Jul/10 ]

Actually I personally think the only possible solution here is to offload this
to the server, instead of issuing <update id="javax.faces.ViewState"> we have to
extend the protocol here so that the client is notified which form and viewstate
element needs to be updated.
I am not sure if updating all forms automatically really resolves the issue,
because in a portlet scenario this does not work out, how about client side
state saving or even worse if someone introduces multiple viewroots
programmatically just as portlets do?

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by frederickkaempfer [ 21/Sep/11 ]

The same problem occurs (in Mojarra 2.1.3) when the entire ViewRoot is replaced via ajax. In that case none of the forms get their view state updated. You need to submit a form at least twice in order to trigger the execution of the full JSF lifecycle. The first time only a new ViewState field is created in the submitted form.

At least all forms contained in the rendered section need to have their view state field updated. In the current implementation a ViewState field is only created if the render target is it self a form (not a parent of forms).

Updating all forms on the page is also a possibility though strictly speaking forms not contained in the <update/> section of the Ajax request are not part of the newly generated view state.

Possible duplicates of this bug I found so far:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1024
http://java.net/jira/browse/JAVASERVERFACES-2199

Comment by frederickkaempfer [ 22/Sep/11 ]

I have created a fix for the issue, which updates the ViewState field for forms which are children of the specified render targets.

Furthermore it handles the case where render="@all" is used. In this case all forms in the document will have their ViewState field updated. Previously this caused forms to loose their ViewState.

Note that this fix does not update all forms in the document, but only those which have been re-rendered (thus are part of the newly generated view on the server).

Comment by werpu12 [ 22/Sep/11 ]

Actually I have similar fixes for myfaces, I basically update all forms which have render targets in or forms which are part of a render target.
Additionally to that I added a update all config option which is outside of the spec.
But nevertheless.

But that is just a hack in my opinion. The root problem is in the protocol.
The protocol simply needs to deliver a list of form ids which need a viewstate update.
So I personally think the only viable long term solution to this problem simply is to update the protocol of jsf 2.2 in this regar ala <update id="javax.faces.ViewState" updateIds="id1 id2 id3">dkghsfkjgh</update> or for backwards compatibility reasons introduce an entirely new tag like <updateViewState id="...">....

Comment by rogerk [ 22/Sep/11 ]

Your workarounds are fine for now, but clearly this needs to be a spec change for the better.

Comment by frederickkaempfer [ 22/Sep/11 ]

If it was safe to assume that the ViewState does not change during a partial request the logic can be simplified by updating ALL forms in the document (not just render targets).

In Mojarra's ServerSideStateHelper (line 200) this assumption holds true, but I did not find anything in the spec enforcing this.

Additionally this would also take care of any Form dynamically added to the view or any render ids added via facesContext.getPartialViewContext().getRenderIds().add(...);

Right now only the "javax.faces.partial.render" argument is consulted which is indeed suboptimal.

I can change the workaround to simply update all forms in the page, which would also make it less of a "Hack". What do you think?

Comment by rogerk [ 22/Sep/11 ]

I was thinking along those same lines..
In which case we would not need to introduce a new response element as Werner mentioned.
It's been sometime since we looked at this - it has been discussed before.
Are there any portlet implications (namespace related) by doing this (that was brought up - but could be for a different issue)..

Comment by werpu12 [ 22/Sep/11 ]

Actually there are portlet implications, hence i stayed away from updating all forms automatically, but made it a config option you can turn on in myfaces.

The implication is that different portlets can host different forms under different viewroots and hence have different viewstates.
Now the main problem is, we dont have any viewroot information. So it comes down to following:
a) either send the viewstate info with an altered protocol i mentioned

  • safe since every form must have a unique id in the dom no double ids are allowed

b) add viewroot information and then update all forms under the corresponding viewroot - should be safe as well but is in my opinion not as clean as option a) and probably causes an alteration of the protocol as well (ala introduction of a viewroot element) or on the api side. I am not sure if we have a scenario where we have different viewstates under one viewroot though. I never really bothered to look deeper into this aspect of the jsf spec.

c) Try to move forward with the usual hacks - worst option of all

In my personal experience this multi form issue has been a huge issue for the users, I had about 5-10 requests on the myfaces mailinglist where users had problems and thought it was an issue of the implementation.

Comment by frederickkaempfer [ 23/Sep/11 ]

It's true that updating all forms won't work in any case where there are multiple viewroots involved. Anyhow I was hoping to find a solution that is usable even with the 2.1 and 2.0 spec versions, because this bug is not an enhancement, but currently breaks a couple of basic Ajax features in JSF. To summarize them quickly:

1. Specifying parents of forms as render targets.
2. Using the @all render target on any page with multiple forms.
3. Replacing the entire viewroot, for example via <h:commandLink action="myNavigationOutcome"><f:ajax/></h:commandLink>
4. Dynamically adding RenderIds that include forms in JSF Lifecycle with facesContext.getPartialViewContext().getRenderIds().add(...)

The workaround I provided should at least make 1-3 work again. Updating all forms in the document would make 1-4 work, but as you said will break Portlet compatibility.

There is another option to consider that does not require a protocol change:

Before the doUpdate function is called for any of the changes read the view state information at the end of the partial response document and save it in a variable in the jsf.ajax.response function. the viewstate can then be passed to any call of doUpdate function, which can then take care of creating view state fields where it is appropriate. This way we would not have to redundantly send the render ids, as they already provided as the <update> ids.

Comment by frederickkaempfer [ 23/Sep/11 ]

Here is a changebundle that updates the ViewState for each form element that is replaced during the ajax update.

I wonder if a Spec change is even necessary because: If a form is processed during an update it means that its ViewState field has to be updated (or created) as well. With this patch it is now done in the doUpdate function. On the other hand, if a form is not re-rendered there is no compelling reason to update its ViewState field, because if it had been changed on the server-side this would not be visible in the browser.

So following this logic, specifying the "updateIds" in a new protocol element will always replicate the render ids which are already contained in the <update> tags (or any of the forms contained in them, which can also be found using JavaScript, like it is done in the provided patch).

Do you think this is still too "hack"-ish?

Comment by werpu12 [ 23/Sep/11 ]

Unfortunately things are not that simple. I cannot speak for mojarra, but I assume it is similar, but myfaces has a meta information in the viewstate which also pinpoints to the viewid (and the state history as well) so if you do not update a second form even if you dont have a rerender there, you basically at a submit from that form can get a cannot find viewid once it drops out of the view history.

So we have two problems
a) update all forms automatically is prevented due to the fact that it breaks in a portlet environment

b) not updating not rendered forms might break the state history information of the viewstate not updated

So a pure javascript fixup will work and might work under normal non portlet circumstances (the simplest one probably is simply to update all forms for a normal webapp) but it will break in corner cases like portlet environments. Thats one of the reasons why I implemted about three fallback modes for this problem in myfaces. So that if even one fallback fails the user can switch to another one which might suite to his environment.

Comment by frederickkaempfer [ 23/Sep/11 ]

I think Mojarra does not even change the ViewState during partial requests.

Nevertheless I suppose there are two separate issues surfacing here that are remotely related. This patch should work in a Portlet scenario as well as the unpatched version and it fixes the 4 issues I mentioned earlier including the initial bug report. Contrary to updating all forms in the document, it doesn't make it any worse for the portlet scenario. But yes, it is a preliminary hack, if you consider the following change as the right way to handle the situation:

In your last comment you basically said that on each Ajax request all forms contained in a one ViewRoot have to be updated with new state information - at least in the case of MyFaces (it would work for Mojarra as well because the ViewState doesn't change):

  • If we are in a "normal" (non-portlet) environment with just one ViewRoot, this means updating all forms contained in the entire document.
  • If we are in a portlet environment it would mean updating all forms that are contained in the current ViewRoot.

So wouldn't the best course of action be your option b): make it possible to specify the view root element's id additionally in the partial response. If it is not specified or is set to a default value, update the entire document, if not only update forms contained in the viewroot element. This would also add the possibility to rerender a complete portlet with the special render target @all, which represents entire ViewRoot element. Sadly I don't know enough about the portlet spec to tell if this is a good idea and if this change is enough to support it properly.

Providing a list of update ids would then again be redundant, because the forms that need updating depend only on the ViewRoot that is currently - partly or in whole - redisplayed.

If this sounds like the right way to do it, then applying the changebundle will be counterproductive, because it is unnecessarily complex compared to updating all forms in the current ViewRoot. On the other hand it could even be backported to 2.0 or 2.1, it does not make things worse for portlets and it fixes the 4 critical bugs/problems i mentioned.

Comment by Ed Burns [ 23/Sep/11 ]

Thank you for excellent and clear analysis. Given my desire to include sketches for JAVASERVERFACES_SPEC_PUBLIC-730, JAVASERVERFACES_SPEC_PUBLIC-517, and JAVASERVERFACES_SPEC_PUBLIC-802, in next week's EDR of the spec, I'm going to defer this til after JavaOne.

Comment by codylerum [ 02/Nov/11 ]

This also is an issue with popup panels which often have their own form that when submitted rerenders content on the main page.

Since any forms on the main page did not participate in the submit they don't rerender with a viewstate and are unusable.

Comment by mdirkse [ 06/Dec/11 ]

Added a javascript workaround that fixes this issue and can be executed via the browser onLoad event handler. There are 2 versions: a plain JS one, and a jQuerified one. Tested and confirmed for Mojarra 2.1.2 (and jQuery 1.7.x).
Mad propz to frederickkaempfer for the original JS code.

Comment by werpu12 [ 06/Dec/11 ]

Sorry to crush some hopes here, but the posted solution is exactly the one I have in myfaces for the non portlet case (you can turn it on via a config param). And there it works, but it can only work in a non portlet environment, because there you have only one viewroot. So you can update all forms under document.

In a portlet environment you can have several viewroots under document with independend viewstates and independend forms. There the patch ultimately will break your portlet environment by applying wrong viewroots to other portlets. Thats because the which dom node is the viewroot info is simply missing on the client side and/or the protocol.

As I said before unless you have the viewroot info or you know which forms you update there is no way to resolve that issue for the portlet and non portlet case at the same time. The problem really is a problem of the protocol not the implementation.

Comment by rogerk [ 06/Dec/11 ]

I agree with Wevner's earlier assessment - that to handle the portlet case - multiple independent view root (eaxh with one or more forms) - we do need a new "server to client" message protocol that draws the association of which forms the view state should apply.

Comment by mdirkse [ 06/Dec/11 ]

werpu12 is right, the workaround I posted only works for the non-portlet case (and is only verified for mojarra 2.1.2)

Comment by sharath.naik [ 29/Dec/11 ]

Updating the MultiViewHandler's [ public void writeState(FacesContext context) throws IOException ] seems to fix the issue. The change made is to add the view state hidden field for forms, even when is a ajax request.

What is the purpose of not writing the view state if it is a partial request in this method?

Attaching the custom ViewHandler to override this method. would this be a fix that can be considered to be moved to MultiViewHandler?

Comment by frederickkaempfer [ 02/Jan/12 ]

@ sharath.naik: It's probably left out because the jsf ajax response already includes the view state information in an <update> tag, so the field can be created using JavaScript.

As I said earlier, the minimum a JSF implementation should do is update the view state information for all forms included in the render target list. I don't see how this creates any new problem in the portlet environment and that is what the latest changebundle I submitted does. Currently the algorithm detailed in the spec is not general enough and should be corrected.

A broader approach is to update all forms under the current view root. For that a protocol extension is necessary which tells the client which DOM element represents the view root. It would also enable scenarios where the whole view root is replaced (like @all and navigation) for the portlet environment. In my opinion for this a new spec enhancement should be issued.

Comment by codylerum [ 15/Feb/12 ]

Is the attached workaround meant to be called from the oncomplete of an ajax component or am I missing another way to trigger it?

Comment by frederickkaempfer [ 22/Feb/12 ]

@codylerum: it should be enough to execute the script once on a page load, after jsf.js is loaded of course.

Comment by Ed Burns [ 03/May/12 ]

TG> (First of all, javax.faces.ViewState should not be modified for Ajax
TG> updates using server-side state-saving, but this simple approach
TG> does not appear to be the current direction.)

Can you please elaborate more on what you mean by this? The issue
doesn't mention anything about Ajax specifically. Is this a separate
concern you are raising, Ted?

TG> We are a bit unclear on how the current implementation is intended
TG> to work, but expect that something like the following is necessary:

TG> When the request is submitted, call
TG> getElementsByName('javax.faces.ViewState') and store the list of IDs
TG> for all with equal value to that of the javax.faces.ViewState in the
TG> submitting form. In the case of future JSP inclusion or current
TG> Portlets, there will be javax.faces.ViewState fields not associated
TG> with the current view. They will have different values and are not
TG> included in the list.

TG> When the partial response is generated, it may contain rendered
TG> hidden inputs with name javax.faces.ViewState and unique IDs, but
TG> also contains the special case <update
TG> id="javax.faces.ViewState"><![CDATA[...]]></update>. The previously
TG> stored list of IDs are now all updated to use the new value. Any
TG> javax.faces.ViewState hidden fields that have been modified by the
TG> page update itself (potentially now having different IDs) have the
TG> correct value anyway because they were just updated.

These two comments are better suited to JAVASERVERFACES_SPEC_PUBLIC-790,
so I'll copy them there. Ted, can you please take a look at 790 and see
if you agree that your comments pertain more to that issue than this
one?

Comment by tedgoddard [ 07/May/12 ]

At least in the case of MyFaces, this complicates things considerably:

"Unfortunately things are not that simple. I cannot speak for mojarra, but I assume it is similar, but myfaces has a meta information in the viewstate which also pinpoints to the viewid (and the state history as well) so if you do not update a second form even if you dont have a rerender there, you basically at a submit from that form can get a cannot find viewid once it drops out of the view history."

It makes it necessary to update the ViewState key for every request. I was under the impression that a similar strategy was being considered for Mojarra.

In my above comments, I assume that the form Renderer would be modified to always write out the ViewState (even for partial rendering). Alternatively, the javax.faces.ViewState fields could be updated via two cases:

  • javax.faces.ViewState found in the current HTML document that match the submitting javax.faces.ViewState will be updated after the current response
  • javax.faces.ViewState found in the updated regions will be updated after the current response

This should handle portlet, servlet inclusion, and multiple form cases.

Comment by boogi [ 31/May/12 ]

Hi,
It says on fix version "2.2 Sprint 12" but it appears as unresolved on that sprint.
Do you a new estimation for the solution of this issue?

Comment by javaone9 [ 02/Nov/12 ]

I tried 2.1.14. it did not work.
I think this issue is urgent for any applications.

Comment by frederickkaempfer [ 18/Apr/13 ]

Please don't forget this issue for 2.2. It's one of the most annoying and frustrating aspects of the JSF Ajax experience. It would be a shame if the JSF community would have to wait another spec release -possibly another year- before this gets fixed.

tedgoddard made it very clear how to proceed with this issue in the previous comment.

Thanks a lot.

Comment by kfyten [ 25/Apr/13 ]

Roger/Ed - Just wanted to make it clear that this issue is currently blocking ICEfaces support for JSF 2.2. From a roadmap perspective it would be very helpful to us if this JIRA could be updated to reflect the current reality in terms of whether/when this issue may be resolved prior to 2.2 final release.

Thx.

Comment by rogerk [ 26/Apr/13 ]

Unfortunately I don't believe this made it into 2.2.

Comment by balusc [ 08/May/13 ]

This is really unfortunate.

In the meanwhile, developers can use this script to workaround the issue: http://balusc.blogspot.com/2011/09/communication-in-jsf-20.html#AutomaticallyFixMissingJSFViewStateAfterAjaxRendering

Comment by frederickkaempfer [ 08/May/13 ]

@balusc: I think that the workaround scripts have to be changed for 2.2, because the id of the ViewState field has been changed slightly. I didn't yet have time to look into it.

Comment by arjan tijms [ 08/May/13 ]

I think that the workaround scripts have to be changed for 2.2, because the id of the ViewState field has been changed slightly. I didn't yet have time to look into it.

They have changed indeed, see http://jdevelopment.nl/jsf-22/#220 and JAVASERVERFACES_SPEC_PUBLIC-220 for more details about this.

Comment by codylerum [ 08/May/13 ]

This is one of the larger pain points for developers utilizing ajax so it is very unfortunate that we are likely looking at years for resolution. Can anything be done at this point to speed that up?

Currently this issue has almost 2x the votes of the next closest issue.

Comment by swathireddy12 [ 22/Aug/13 ]

I am making use of JSF 1.2 version of jars (myfaces-api-1.2.9.jar ,myfaces-impl-1.2.9.jar,trinidad-api-1.2.13.jar,trinidad-impl-1.2.13.jar).
I am trying to retrieve the javax.faces.ViewState using the id attribute in a Javascript which works.

But i still don't see the id attribute in the loaded page
<input type="hidden" name="javax.faces.ViewState" value="!-14uywjgjai">

Could you please tell me if this is an issue with JSF 1.2 version as well?
Or once the page is rendered the id attribute associated with "javax.faces.ViewState" is not seen anymore.

Comment by werpu [ 22/Aug/13 ]

No this is a JSF 2.x issue only. This has nothing to do with JSF 1.2.

Comment by balusc [ 13/Jan/14 ]

This is one of the larger pain points for developers utilizing ajax so it is very unfortunate that we are likely looking at years for resolution. Can anything be done at this point to speed that up?

For exactly this reason, it has been added to OmniFaces 1.7: http://showcase.omnifaces.org/scripts/FixViewState

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.

Comment by donvip [ 25/May/16 ]

Is this issue going to be fixed in JSF 2.3?

Comment by arjan tijms [ 25/May/16 ]

Is this issue going to be fixed in JSF 2.3?

I think we should definitely address this for 2.3. Thanks for the reminder!

Comment by balusc [ 30/May/16 ]

I'm currently looking at this.

As far as I see there are several solutions being proposed:

  1. Let JS blindly update/add view state of every single form in document - bad, might not work in portlet and might add noise to GET forms and/or non-JSF forms.
  2. Let JS update only missing view state of every single POST form in document - unclear if this works in portlets too.
  3. Let JS update only view states of all POST forms covered in ajax update targets - unclear if this works in portlets too.
  4. Always write view state to response - requires major spec change in ViewHandler#writeState(). I'd rather not do that.
  5. Include client IDs of all POST forms covered in ajax update targets in meta information of partial response.

I tend to implementing #3. Who can confirm if that will indeed work for portlets? Otherwise we'd better go for #5.

OmniFaces FixViewState by the way follows #2.

Comment by werpu [ 30/May/16 ]

The way I see it the ultimate fix on this issue, is a protocol change for the ajax response, we simply need the meta information there which viewstates in which forms need to be updated.
Everything else is a hack.

Comment by balusc [ 30/May/16 ]

Completely agree that. I updated the previous comment.

Comment by balusc [ 02/Jun/16 ]

Still no feedback from portlet guys.

I checked how MyFaces did it. They basically follows #2 with two little differences: it (incorrectly) updates GET forms too, and it skips everything when running in portlet environment.

Comment by werpu [ 02/Jun/16 ]

For multiform scenarios in no portlet environemnts I also added a config param which basically allows to override the default behavior and updates all forms reachable. This solved the multiform problem for many users since portlets are rather seldomly used.

Comment by werpu [ 02/Jun/16 ]

#2 simply turned out to be incorrect in multiform non portlet scenarios because the viewstate is kept over more than one form in the standard cases.
but also updating all forms is a no go for portlets, hence the config hack on my side.

Comment by balusc [ 02/Jun/16 ]

It's still not clear to me if #3 works for portlets. If it does, then #5 could be specified and implemented following same logic (i.e. update only JSF forms which are covered in ajax update targets).

Comment by donvip [ 02/Jun/16 ]

@balusc: thanks for the updates. The status on MyFaces is interesting, I didn't know they had implemented a workaround. Can you please tell me where I can find it? Is there an existing bug report/pull request concerning their incorrect implementation?

Comment by Neil Griffin [ 03/Jun/16 ]

@balusc, @werpu: Thank you for considering the portlet use-case. I think we can make #3 work in a portlet environment, but need to make sure that the javax.faces.ViewState hidden field values are only updated for forms that are associated with the portlet that invoked the XHR. (In other words, there could be other JSF portlets that are part of the HTML document that should not be touched by jsf.js, even though they share the same jsf.js resource).

In a portlet environment the UIViewRoot implements NamingContainer, thanks to javax.portlet.faces.component.PortletNamingContainerUIViewRoot

Because of this, the "id" attribute of forms is namespaced with the portlet id. For example, given this XHTML:

<h:form id="a">...</h:form>
<h:form id="b">...</h:form>

The following HTML would be rendered to the response:

<form id="Pluto_test_portlet_1__24955534_0_:a">...</form>
<form id="Pluto_test_portlet_1__24955534_0_:b">...</form>

If you consider the following XHR response:

<partial-response id="Pluto_test_portlet_1__24955534_0_">
  <changes>
    <update id="Pluto_test_portlet_1__24955534_0_:javax.faces.ViewState:0">
      <![CDATA[4617973942428228781:-2797886012162436717]]>
    </update>
  </changes>
</partial-response>

Then jsf.js could use the Pluto_test_portlet_1_24955534_0 namespace to make sure it only updates javax.faces.ViewState hidden fields in forms that contain that namespace in their "id" attribute.

As a side note, the portlet namespace is known to Mojarra as "namingContainerId" when it builds up mojarra.ab JavasScript. For more information, see AjaxBehaviorRenderer.java and jsf.js. Mojarra uses it to namespace XHR parameters such as javax.faces.partial.ajax in a portlet environment that requires strict parameter namespacing. The XHR parameter namespacing feature is unique to Mojarra – it has not yet been contributed to MyFaces.

Comment by balusc [ 06/Jun/16 ]

OK, I will propose the following API changes for JSF 2.3:

1. PartialResponseWriter#startDocument(): if UIViewRoot is available, then write UIViewRoot#getContainerClientId() as value of the id attribute of the <partial-response> element. Both Mojarra and MyFaces already implement this (although currently unspecified). In Mojarra's jsf.js, this value must replace/substitute the Mojarra-specific namingContainerId variable (which however appears to be already partially prepared for this, given the presence of a partialResponseId variable in doUpdate function which is totally unused). Portlets can then interpret this value as their parameter namespace (this is exactly what the Mojarra-specific namingContainerId did).

2. Correct an incorrect statement in the javadoc of ViewHandler#writeState() - it currently says that the <update> for javax.faces.ViewState is written into Ajax response during UIViewRoot#encodeEnd(). But this is untrue, in both Mojarra and MyFaces it actually takes place during PartialViewContext#processPartial(). I'll leave the reasoning for this deviation in the middle as this appears to be an oversight. Although I personally find that it makes more sense if it takes place during PartialResponseWriter#endDocument.

3. Update PartialViewContext#processPartial() to specify that during render response phase, the <update> for javax.faces.ViewState will be written, along with id attribute of exactly UIViewRoot#getContainerClientId() + UINamingContainer#getSeparatorCharacter() + ResponseStateManager#VIEW_STATE_PARAM. Currently, both Mojarra and MyFaces already implement this with one minor difference: an incremental counter identifying the form is being suffixed, this is now unnecessary.

4. Update the JSF 2.2 section (orange) of jsf.ajax.response jsdoc to remove <UNIQUE_PER_VIEW_NUMBER> altogether as below (changes in bold, strikeout means removal):

If an <update> element is found in the response with an identifier containing javax.faces.ViewState:

<update id="<VIEW_ROOT_CONTAINER_CLIENT_ID><SEP>javax.faces.ViewState">
   <![CDATA[...]]>
</update>

locate and update the submitting form's javax.faces.ViewState value with the CDATA contents from the response. <SEP>: is the currently configured UINamingContainer.getSeparatorChar(). <VIEW_ROOT_CONTAINER_CLIENT_ID> is the return from UIViewRoot.getContainerClientId() on the view from whence this state originated. <UNIQUE_PER_VIEW_NUMBER> is a number that must be unique within this view, but must not be included in the view state. This requirement is simply to satisfy XML correctness in parity with what is done in the corresponding non-partial JSF view. Locate and update the javax.faces.ViewState value for all forms specified covered in the render target list whose ID starts with the same <VIEW_ROOT_CONTAINER_CLIENT_ID> value.

The <UNIQUE_PER_VIEW_NUMBER> has no value in the API

@werpu: what do you think?
@Neil: is this acceptable for portlets?

Comment by Neil Griffin [ 06/Jun/16 ]

@balusc: Thank you for taking the time to propose these changes. Before I comment on your changes, I would like to make you aware of some portlet incompatibilities at are related to javax.faces.ViewState. When you get an opportunity, please read the class-level JavaDoc in ResponseWriterBridgeImpl.java and let me know if it might be appropriate to fix these incompatibilities for JSF 2.3. Thank you.

Comment by balusc [ 07/Jun/16 ]

I gather you're talking about limitation #3 in that javadoc? This should already be solved since JSF 2.2 where the javax.faces.ViewState hidden input field ID became namespaced with container client ID.

Comment by Neil Griffin [ 10/Jun/16 ]

@balusc: I'm referring mainly to #2 and #3 in the class-level JavaDoc in ResponseWriterBridgeImpl.java.

#2 is a workaround for the code in jsf.js that interprets <update id="javax.faces.ViewRoot">...</update> to mean replacing the <body>...</body> of the HTML document. I just created JAVASERVERFACES_SPEC_PUBLIC-1421 in order to see if the JSF EG would consider fixing jsf.js – it might be that the EG decides that this is a bridge concern and that the workaround should become a bridge requirement in JSR 378.

#3 is a workaround that causes the javax.faces.ViewState hidden field to always be rendered before the closing </form> tag when a partial-response is being written. It works around the code in jsf.js that attempts to add the hidden field to the DOM which fails in a portlet environment. This problem happens when a navigation-rule executes during an XHR. Specifically, the form that was submitted via f:ajax is no longer part of the DOM, since the entire portlet <div>...</div> section was replaced due to navigation to a different viewId. I suppose that the appropriateness of this workaround might be determined by the outcome of JAVASERVERFACES_SPEC_PUBLIC-1421.

Since this is all somewhat off-topic, I will provide feedback on your proposed API changes in a follow-up comment.

Comment by Neil Griffin [ 11/Jun/16 ]

@balusc: Your proposed API changes look good. However, should jsf.js need to add a javax.faces.ViewState hidden field to the DOM on-the-fly, the value of the name attribute should be prefixed by the namingContainerId. Looks like there is a bug in jsf.js in this regard. If you have time in your schedule, it would be great if you could fix the bug as part of your prototype work. Thanks, Neil.

Comment by balusc [ 11/Jun/16 ]

#2 is unrelated to the current issue. It's good you created issue 1421 on this.

I will keep the field name bug in mind. I only think it should be prefixed at the moment ajax request is to be sent, as done for all other params, not at the line you pointed out.

Comment by Neil Griffin [ 13/Jun/16 ]

That's fine to prepend the namespace at the time the request is sent. At first glance it looked like a bug to me because the bridge causes the namespace to be prepended when a component is rendered to the response.

Comment by Neil Griffin [ 14/Jun/16 ]

@balusc: Regarding the lines I mentioned in jsf.js – after the element is added to the DOM dynamically, then if the form is subsequently submitted without f:ajax (full-page postback) then the lack of a prepended namespace would be a problem.

Comment by balusc [ 17/Jun/16 ]

I see, will keep that in mind.

Comment by balusc [ 20/Jun/16 ]

Pushed: https://java.net/projects/mojarra/sources/git/revision/ff26c4dccafd50d22757ce8562230e31f9768033

@Neil: please let me know if that works for portlets as well and you could further reduce current workarounds in portlet side. FYI: the initial Mojarra implementation incorrectly omitted namingcontainer separator character from namespace prefix in ajax specific parameters. I have fixed that as well (and renamed Mojarra-specific RequestParameterMap#getNamingContainerId() to RequestParameterMap#getNamingContainerPrefix(), just in case you were relying on it).

@werpu: please let me know if the JSF/JS API changes are clear enough for MyFaces. Here's a summary:

ViewHandler#writeState(FacesContext)

@@ -737,8 +737,9 @@ public abstract class ViewHandler {
      * <code>Ajax</code> requests, the state is obtained by calling
      * {@link StateManager#getViewState}
      * and then written into the <code>Ajax</code> response during final
-     * encoding 
-     * ({@link javax.faces.component.UIViewRoot#encodeEnd}. 
+     * encoding <span class="changed_modified_2_3">
+     * ({@link javax.faces.context.PartialViewContext#processPartial(javax.faces.event.PhaseId)})
+     * </span>.
      * </p>
      *
      * @param context {@link FacesContext} for the current request

PartialViewContext#processPartial(PhaseId)

@@ -314,6 +317,17 @@ public abstract class PartialViewContext {
      * <code>Collection</code> returned from {@link #getExecuteIds} 
      * and {@link #getRenderIds} will be processed.</p>  
      *
+     * <p class="changed_added_2_3">When the indicated <code>phaseId</code>
+     * equals {@link PhaseId#RENDER_RESPONSE}, then obtain the state by calling
+     * {@link StateManager#getViewState} and write out it as an update element
+     * with an identifier of
+     * <code>&lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt;&lt;SEP&gt;javax.faces.ViewState</code>
+     * where <code>&lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt;</code> is the return
+     * from {@link UIViewRoot#getContainerClientId(FacesContext)} on the view
+     * from whence this state originated, and <code>&lt;SEP&gt;</code> is the
+     * currently configured
+     * {@link UINamingContainer#getSeparatorChar(FacesContext)}.</p>
+     *
      * @param phaseId the {@link javax.faces.event.PhaseId} that indicates
      * the lifecycle phase the components will be processed in. 
      */ 

PartialResponseWriter#startDocument()

@@ -113,6 +116,10 @@ public class PartialResponseWriter extends ResponseWriterWrapper {
 
     /**
      * <p class="changed_added_2_0">Write the start of a partial response.</p>
+     * <p class="changed_added_2_3">If {@link UIViewRoot} is an instance of
+     * {@link NamingContainer}, then write
+     * {@link UIViewRoot#getContainerClientId(FacesContext)} as value of the
+     * <code>id</code> attribute of the root element.</p>
      *
      * @throws IOException if an input/output error occurs
      * @since 2.0

jsf.ajax.request

@@ -2048,7 +2061,8 @@ if (!((jsf && jsf.specversion && jsf.specversion >= 20000 ) &&
              * <p><b>Implementation Requirements:</b></p>
              * This function must:
              * <ul>
-             * <li>Be used within the context of a <code>form</code>.</li>
+             * <li>Be used within the context of a <code>form</code><span class="changed_added_2_3">,
+             * else throw an error</span>.</li>
              * <li>Capture the element that triggered this Ajax request
              * (from the <code>source</code> argument, also known as the
              * <code>source</code> element.</li>
@@ -2059,6 +2073,16 @@ if (!((jsf && jsf.specversion && jsf.specversion >= 20000 ) &&
              * <li>If the <code>source</code> argument is a <code>string</code>, find the
              * DOM element for that <code>string</code> identifier.
              * <li>If the DOM element could not be determined, throw an error.</li>
+             * <li class="changed_added_2_3">If the <code>javax.faces.ViewState</code> 
+             * element could not be found, throw an error.</li>
+             * <li class="changed_added_2_3">If the <code>javax.faces.ViewState</code> 
+             * element has a <code>&lt;update id="&lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt;&lt;SEP&gt;</code>
+             * prefix, where &lt;SEP&gt; is the currently configured
+             * <code>UINamingContainer.getSeparatorChar()</code> and
+             * &lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt; is the return from
+             * <code>UIViewRoot.getContainerClientId()</code> on the
+             * view from whence this state originated, then remember it as <i>namespace prefix</i>.
+             * This is needed during encoding of the set of post data arguments.</li>
              * <li>If the <code>onerror</code> and <code>onevent</code> arguments are set,
              * they must be functions, or throw an error.
              * <li>Determine the <code>source</code> element's <code>form</code>
@@ -2175,7 +2199,10 @@ if (!((jsf && jsf.specversion && jsf.specversion >= 20000 ) &&
              * </li>
              * </ul>
              * </li>
-             * <li>Encode the set of post data arguments.</li>
+             * <li>Encode the set of post data arguments. <span class="changed_added_2_3">
+             * If the <code>javax.faces.ViewState</code> element has a namespace prefix, then
+             * make sure that all post data arguments are prefixed with this namespace prefix.
+             * </span></li>
              * <li>Join the encoded view state with the encoded set of post data arguments
              * to form the <code>query string</code> that will be sent to the server.</li>
              * <li>Create a request <code>context</code> object and set the properties:

jsf.ajax.response

@@ -2613,8 +2639,9 @@ if (!((jsf && jsf.specversion && jsf.specversion >= 20000 ) &&
              * correctness in parity with what is done in the
              * corresponding non-partial JSF view.  Locate and update
              * the <code>javax.faces.ViewState</code> value for all
-             * forms specified in the <code>render</code> target
-             * list.</li>
+             * POST forms covered in the <code>render</code> target
+             * list whose ID starts with the same 
+             * &lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt; value.</li>
 
              * <li class="changed_added_2_2">If an
              * <code>update</code> element is found in the response with
@@ -2639,8 +2666,9 @@ if (!((jsf && jsf.specversion && jsf.specversion >= 20000 ) &&
              * correctness in parity with what is done in the
              * corresponding non-partial JSF view.  Locate and update
              * the <code>javax.faces.ClientWindow</code> value for all
-             * forms specified in the <code>render</code> target
-             * list.</li>
+             * POST forms covered in the <code>render</code> target
+             * list whose ID starts with the same 
+             * &lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt; value.</li>
 
 
              * <li>If an <code>update</code> element is found in the response with the identifier
Comment by Neil Griffin [ 25/Jun/16 ]

@balusc: Thank you for making the commit. I hope to have time on Monday June 25 to review the code changes.

Comment by Neil Griffin [ 27/Jun/16 ]

@balusc: On line 1022 of Util.java, instead of:

Util.java
return viewRoot.getContainerClientId(context) + UINamingContainer.getSeparatorChar(context);

Would you instead consider:

Util.java
return viewRoot.getContainerClientId(context);

I admit that it is inconsistent to have UIInput name attribute values to be rendered as namespace + ":" + clientId but not include ":" for hidden fields like javax.faces.ViewRoot.

However, that's the way it was implemented in Mojarra 2.2 and it fits more naturally with the Faces Bridge as well as the method of namespacing parameters encouraged by the Portlet API. Thank you.

Comment by balusc [ 28/Jun/16 ]

How does that work for regular input fields? They are also namespaced this way. With those JSF API changes, it should theoretically not be necessary anymore to override the request parameter map this way and just rely on standard JSF implementation. Those API changes are meant to further reduce code in Portlet bridge and let JSF do the work.

Comment by Neil Griffin [ 28/Jun/16 ]

The Faces Bridge's implementation of ExternalContext.getRequestParameterMap() decorates a PortletRequest, so it is not possible to use com.sun.faces.context.RequestParameterMap since it decorates a ServletRequest.

The reason why input fields work is because decode methods automatically include the namespace prefix (and the separator char) by asking for a parameter value with getClientId() as the parameter name, like this:

FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap(uiInput.getClientId());

For example, see HtmlBasicRenderer.java

Lookups for request parameters like javax.faces.ViewState do not automatically include the namespace prefix, which means that the Faces Bridge's implementation of ExternalContext.getRequestParameterMap() must account for this.

A good example is ResponseStateManagerImpl.java.

Comment by balusc [ 04/Jul/16 ]

I see, the problem boils down to that JSF impl is internally not prefixing the standard parameters with naming container client ID when the UIViewRoot is an instance of NamingContainer. If that part is fixed, then the whole RequestParameterMap approach becomes unnecessary. And, then the portlet case will also start to work correctly, right?

Comment by balusc [ 04/Jul/16 ]

Neil/Werpu, how about this change on UIViewRoot#encodeChildren()?

     * <p class="changed_added_2_3">If this {@link UIViewRoot} is an instance of {@link NamingContainer}, then the JSF
     * implementation must ensure that all encoded POST request parameter names are prefixed with
     * {@link UIViewRoot#getContainerClientId(FacesContext)} as per rules of {@link UIComponent#getClientId(FacesContext)}.
     * This also covers all predefined POST request parameters such as {@link ResponseStateManager#VIEW_STATE_PARAM},
     * {@link ClientBehaviorContext#BEHAVIOR_SOURCE_PARAM_NAME} and {@link PartialViewContext#PARTIAL_EVENT_PARAM_NAME}.
     * </p>
 

I implemented this locally on Mojarra and all unit tests have passed. I didn't yet remove Mojarra internal RequestParameterMap just to ensure backwards compatibility.

Comment by balusc [ 06/Jul/16 ]

Neil, above proposed implementation changes have been committed as per https://java.net/projects/mojarra/sources/git/revision/3b1d1e2a1330c6789f566f36597b6b9fcb81d509 so you have the opportunity to test it against your Portlet case.

Only API change (the above Javadoc proposal) has not been committed yet due to lack of confirming feedback.

Comment by lu4242 [ 20/Jul/16 ]

Other post parameters that could be included are javax.faces.RenderKitId (ResponseStateManager#RENDER_KIT_ID_PARAM) and javax.faces.ClientWindow (ResponseStateManager#javax.faces.ClientWindow).

Comment by balusc [ 20/Jul/16 ]

Indeed. There are more. Should we specify them all? I have in Mojarra at least collected them as RenderKitUtils.PredefinedPostbackParameter enum. There are so far 9 of those: https://github.com/javaserverfaces/mojarra/blob/3b1d1e2a1330c6789f566f36597b6b9fcb81d509/jsf-ri/src/main/java/com/sun/faces/renderkit/RenderKitUtils.java#L181

Comment by balusc [ 21/Jul/16 ]

I've pushed the javadoc changes: https://java.net/projects/mojarra/sources/git/revision/1569145562d8c20cc924f0eb5343b5e931df352d. For now, the issue is technically solved in JSF API and Mojarra impl.

Before I close off the issue, please let me know if there are any things unclear or missing, particularly with regard to Portlets and MyFaces.

Comment by werpu [ 21/Jul/16 ]

Hi sorry for being so silent, fact is I was extremely busy. I will check the changes tonight and will give my comment either tonight or tomorrow morning. So please keep the issue open at least until tomorrow.

Comment by werpu [ 21/Jul/16 ]

Ok, again sorry for not commenting on this issue for such a long time, I personally like the ViewRoot prepending to javax.faces.ViewState in the id is a reasonable way to go. I can only comment on the ajax client side however. I personally think this solves the problem for me. The original problem was as far as I remember that in the original specs following was written.

If an update element is found in the response with the identifier javax.faces.ViewState:
<update id="javax.faces.ViewState">
<![CDATA[...]]>
</update>
locate and update the submitting form's javax.faces.ViewState value with the CDATA contents from the response.

Which was clearly wrong, since the viewstate should be the same for all forms under one viewroot. Adding the viewroot id fixes this problem once and for all for all cases.
Thanks for your efforts on fixing this long outstanding issue.

Comment by balusc [ 21/Jul/16 ]

Great, thank you for your feedback! Now yet a confirmation from Portlet guys.

Comment by Neil Griffin [ 22/Jul/16 ]

@balusc: I have begun reviewing your recent commits for this issue. Also, I have rebuilt Mojarra 2.3.0-m07 from source and have it running under Pluto 3.0. My goal is to report back tomorrow with more information. Thanks for your patience, Neil.

Comment by Neil Griffin [ 23/Jul/16 ]

@balusc: I have done preliminary testing and have seen good results so far. I still need to do more testing so I ask that you please keep this issue open. Regarding the namespace prefix, please consider the changes in the following pull request: https://github.com/javaserverfaces/mojarra/pull/3

The changes in the pull request remove the separator char from the namespace prefix. That's the way it is implemented in Mojarra 2.2 and it fits more naturally with the Faces Bridge as well as the method of namespacing parameters encouraged by the Portlet API. In addition, component suites like PrimeFaces and ICEfaces namespace their own predefined postback parameters without using the separator char. Thank you.

Comment by balusc [ 23/Jul/16 ]

Namespacing without separator character does not fit naturally in JSF API. I imagined that doing all the namespacing job in JSF side should reduce the work in the Faces Bridge. What work exactly is left in the Faces Bridge that it still needs its own way of namespacing? Then we can look for ways reducing/removing that work. Perhaps a new JSF API method to obtain a namespaced predefined postback parameter without the need to manually check and prefix it?

Comment by Neil Griffin [ 24/Jul/16 ]

@balusc: The convenience of being able to pass a non-namespaced parameter name to the externalContext.getRequestParameterMap().get(String) method has been assumed since JSR 301, and perhaps even by JSF portlet developers over the years. Removing that functionality from the bridge's ExternalContextImpl could be a breaking change for legacy JSF portlets. In fact, there are several places in the Bridge TCK (the TCK that JSR 378 inherited from Oracle) that call externalContext.getRequestParameterMap().get(ResponseStateManager.VIEW_STATE_PARAM) (click here for one example). If you feel that it is important to include the separator char, then we can make an accommodation for that in the bridge's ExternalContextImpl.

BTW I have completed my testing. I am happy to report that the original use-case reported in the description of this issue is now working for portlets. There is just one small bug in jsf.js that needs to be fixed. Line 495 reads:

add(document.getElementById(clientIds[i]));

but it needs to be:

add(document.getElementById(namingContainerPrefix + clientIds[i]));

Thank you, Neil

Comment by balusc [ 24/Jul/16 ]

The convenience of being able to pass a non-namespaced parameter name to the externalContext.getRequestParameterMap().get(String) method has been assumed since JSR 301, and perhaps even by JSF portlet developers over the years

As you can see in Mojarra's source code, this should keep working. I've indeed kept it in for sake of backwards compatibility.

String mapValue = request.getParameter(mapKey);
if (mapValue == null && !mapKey.startsWith(getNamingContainerPrefix())) {
    // Support cases where enduser manually obtains a request parameter while in a namespaced view.
    mapValue = request.getParameter(getNamingContainerPrefix() + mapKey);
}

This is however unspecified in API of the request parameter map. Do you think specifying in API is necessary? In that case, we could probably remove the explicit requirement to namespace predefined postback parameters as it will then happen "automatically" in request parameter map.

Thanks for the jsf.js bug report, I will investigate and fix it.

Comment by balusc [ 24/Jul/16 ]

As to line 495 of jsf.js, this part is fine. The clientIds[i] or f:ajax render is already namespaced (as it is generated by server). The test case associated with issue 790 would otherwise have failed. Line 2501 of jsf.js contains similar part with ids[i] of f:ajax execute which is also already namespaced. This is only not covered by the unit test yet. I will improve the unit test to make sure it's properly being dealt with.

Or did you encounter a problem with this in your test application?

Comment by Neil Griffin [ 25/Jul/16 ]

@balusc: In my testing of line 495 using the JS debugger, clientIds[i] is a JavaScript array of length 1 and the value of clientIds[0] is simply 'a' (it is not namespaced). I can provide you with a downloadable Pluto 3 ZIP if you'd like to try it.

Comment by Neil Griffin [ 25/Jul/16 ]

Do you think specifying in API is necessary?

Yes, I think it would be good to add a sentence to ExternalContext#getRequestParameterMap() and ExternalContext#getRequestParameterValuesMap() that says the map's get(String key) method should first try calling getParameter(key) on the underlying request object, but if it returns null, it should try getParameter(namespacePrefix + key). I suppose that ExternalContext. getRequestParameterNames() method should probably return the namespaced version of the key.

In that case, we could probably remove the explicit requirement to namespace predefined postback parameters as it will then happen "automatically" in request parameter map.

I think it is good to have the requirement that the namespace prefix be written as part of the name attribute of hidden fields. However, if we added the map requirements I mentioned, then line 204 of RenderKitUtils.java would not need to prepend the namespacePrefix.

Comment by balusc [ 25/Jul/16 ]

In my testing of line 495 using the JS debugger, clientIds[i] is a JavaScript array of length 1 and the value of clientIds[0] is simply 'a' (it is not namespaced). I can provide you with a downloadable Pluto 3 ZIP if you'd like to try it.

Is the portlet rendering non-namespaced client IDs? This is confusing. I'd like to see the ZIP and try it, yes.

I think it is good to have the requirement that the namespace prefix be written as part of the name attribute of hidden fields. However, if we added the map requirements I mentioned, then line 204 of RenderKitUtils.java would not need to prepend the namespacePrefix.

I'd prefer consistency over convenience. Otherwise things will be too confusing in long term. If the UIViewRoot is an instance of NamingContainer, it's expected that its ID is prefixed over all place.

Comment by balusc [ 27/Jul/16 ]

While working on https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1372 I think I discovered your problem: invalid client IDs in f:ajax execute/render are not namespaced. I could reproduce it when replacing e.g. render="validClientId" by render="thisDoesNotExist". Can you please reverify?





[JAVASERVERFACES_SPEC_PUBLIC-1193] Declaring component attributes via annotations Created: 11/May/13  Updated: 17/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: arjan tijms Assignee: arjan tijms
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: annotation, annotations, ease-of-use, ease_of_development, no-xml

 Description   

As of JAVASERVERFACES_SPEC_PUBLIC-594, custom components can be declared to be useable in Facelets via the @FacesComponent annotation. Via this it's no longer required to have an entry in a taglib.xml file.

However, if the component author wishes to declare the component's attributes (for documentation, tooling, etc), XML still has to be used.

I therefor would like to propose declaring these attributes via annotations as well.

E.g.

@FacesComponent(value="components.CustomComponent", createTag=true)
public class Foo extends UIComponentBase {

    @Attribute
    String color; // will be injected with getAttributes("color") 

    @Attribute(description="This will determine the ...", required=true)
    String style;

    @Attribute(description="The cost of ... ", default="100")
    Integer cost;

}


 Comments   
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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by c.beikov [ 07/Aug/14 ]

In my opinion the @Attribute annotation should go on an abstract getter and the component class should be declared as abstract. This way you could define reusable behavior in interfaces and inherit these attributes by implementing an interface.
The runtime can just generate an appropriate subclass of a component class that implements those methods. This also gives the implementation flexibility regarding the representation of the data.
If the values of EL expressions are bound to the component instance on creation of the component, how would the component get a changed value if the original EL expression would evaluate to a different value later in the lifecycle?

I implemented an annotation processor that generates these Java classes and XML files based on annotations for me at build time. I think Richfaces did something similar. JSF could just move that process to the runtime.

Comment by Ed Burns [ 17/Aug/15 ]

"Properties" is a hot button topic. It was recently booted out of Java SE 9. This is a decent writeup: http://blog.joda.org/2014/11/no-properties-in-java-language.html





[JAVASERVERFACES_SPEC_PUBLIC-1321] Leverage HTTP2 Server Push from JSF Created: 13/Oct/14  Updated: 08/Aug/16

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Because JSF 2.3 is allowed to depend on Java EE 8, we can take advantage of Servlet 4.0 features such as server push.



 Comments   
Comment by balusc [ 08/Aug/16 ]

Currently, JSF 2.3 already features JSR356 websocket based push as per https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1396





[JAVASERVERFACES_SPEC_PUBLIC-1316] Support @Inject on JSF artifacts Created: 09/Oct/14  Updated: 08/Aug/16

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

Type: New Feature Priority: Critical
Reporter: Manfred Riem Assignee: arjan tijms
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by JAVASERVERFACES_SPEC_PUBLIC-527 Support @Inject for FacesContext Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1309 Support @Inject for ExternalContext Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1323 Support @Inject for the applicationMap Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1327 Verify @Inject HttpSession support Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1333 Support @Inject for UIViewRoot Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1335 Support @Inject for the viewMap Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1345 Support @Inject for the sessionMap Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1349 Support @Inject for FacesConverter Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1350 Support @Inject for FacesValidator Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1351 Support @Inject for FacesBehavior Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1353 Support @Inject for RequestCookieMap Resolved
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1283 Allow for injection on UIComponent, C... Resolved
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-763 Web Container injection support shoul... Closed
is related to JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open
is related to JAVASERVERFACES_SPEC_PUBLIC-1287 Make @javax.faces.bean.ManagedBean me... Closed

 Comments   
Comment by Manfred Riem [ 15/Oct/14 ]

Make sure the following artifacts are mentioned in the spec PDF when describing @Inject support

  • applicationMap
  • externalContext
  • facesContext
  • session (delegating that responsibility back to default CDI runtime)
  • sessionMap
  • view
  • viewMap
  • converters annotated with @FacesConverter (and managed = true)
  • validators annotated with @FacesValidator (and managed = true)
  • behaviors annotated with @FacesBehavior (and managed = true)
  • requestCookieMap
Comment by Ed Burns [ 14/Jan/15 ]

Do you have any plans to support Component, Behavior and Validator?

Comment by Manfred Riem [ 14/Jan/15 ]

In Progress

Comment by Manfred Riem [ 15/Jan/15 ]

Note @Inject on UIComponent instances will not be done as the view state is managed outside of CDI.

Comment by arjan tijms [ 30/Jul/15 ]

Note @Inject on UIComponent instances will not be done as the view state is managed outside of CDI.

IFF there would be an @ComponentScope then as a side-effect of that it may became feasible to allow injection of the UIComponent instances.

Comment by balusc [ 08/Aug/16 ]

Injection of @FacesContext is currently not done properly. It's currently request scoped, but it should actually be "faces context scoped", as an (error) dispatch can create a new FacesContext within the very same request. The current approach will throw ISE from assertNotReleased() when the FacesContext is being referenced in EL.





[JAVASERVERFACES_SPEC_PUBLIC-329] Add new single HTML radio button component that isn't bound to a list Created: 05/Feb/08  Updated: 11/Aug/16

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: rdelaplante Assignee: balusc
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File radio buttons.png    
Issuezilla Id: 329
Status Whiteboard:

cat2 renderkitdoc size_medium importance_small


 Description   

The selectOneRadio component requires that all radio buttons be grouped
together. This is very inflexible when creating user interfaces. Many times I
have encountered screens where I need multiple radio buttons in the same group,
but each radio button exists in a separate area of the screen. This can be done
in HTML easily, but not with JSF's default component set.

I've read that Apache MyFaces has created a component to solve this issue, and
so has Sun's Woodstock component set. Please standardize this fundamental
component in JSF 2.0 so that all implementations come with it.



 Comments   
Comment by rdelaplante [ 05/Feb/08 ]

Created an attachment (id=122)
Example form where this component would be useful

Comment by Ed Burns [ 09/Sep/08 ]

Per 20080827 EG Meeting, push to 2.1

Comment by Ed Burns [ 10/Sep/08 ]

Very early in the development of JSF 2.0, the EG decided we didn't have enough
resources to add new components and that, since components are extensible
anyway, our time would be better spent working on the top five features of 1.
making components easier to develop 2. having first class ajax support for
custom components 3. reducing the configuration burden 4. providing better error
handling and developer experience 5. providing for better interoperability
between 3rd party jsf components.

Comment by rdelaplante [ 10/Sep/08 ]

From my experience, this is the only missing component that maps directly to
HTML. I think this is different from adding fun and useful new components.

In my web apps that don't use sophisticated components such as calendars, I
prefer to use the basic h:* input components so that I don't have to force
hundreds of KB downloads on my users. I style with my own CSS. Since JSF
doesn't offer a radio button component where I can specify the html group name
as an attribute, I have to introduce hundreds of KB download of CSS and
JavaScript to my users by adding a component suite.

Comment by rdelaplante [ 10/Sep/08 ]

This was most noticeable when creating a slim UI for mobile web browsers. If I
wanted to create a UI such as the one in the attached screenshot, mobile users
(smart phones on slow networks) would have to wait 2+ minutes while the
component suite's CSS and JavaScript would download. If JSF had a built in
radio button component that maps to HTML, then this wouldn't be a problem.

Comment by rdelaplante [ 17/Sep/08 ]

I have found a solution for the problem outlined in this ticket without
requiring the addition of a new component. I noticed that issue #229 has added
two new attributes to selectManyCheckbox. All that is missing from
selectOneRadio is a name attribute.

<h:selectOneRadio id="notifyOff" value="OFF" name="notifyType"/>
<h:selectOneRadio id="notifyEmail" value="EMAIL" name="notifyType"/>
<h:selectOneRadio id="notifySMS" value="SMS" name="notifyType"/>

The name attribute is what makes the Woodstock Component Suite's radio button
usable for me, because it lets me have control of the screen layout as shown in
the attached screenshot. If you can add a name attribute to the 2.0 spec that
would be really great!

Comment by rdelaplante [ 17/Sep/08 ]

I meant to refer to issue #228 instead of #229

Comment by rdelaplante [ 23/Mar/09 ]

Here are some examples of how developers have solved this issue:

http://webdev2.sun.com/woodstock-tlddocs/webuijsf/radioButton.html
http://www.icefaces.org/docs/v1_7_2sp1/tld/ice/radio.html
http://myfaces.apache.org/tomahawk-project/tomahawk12/tlddoc/t/radio.html
http://software.topcoder.com/catalog/c_component.jsp?comp=26817861&ver=1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

renderkitdoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by rdelaplante [ 20/Apr/12 ]

I like how the Trinidad and IceFaces radio button works. Essentially what they've done is extend the existing h:selectOneRadio and added a new layout constant value called "spread" which tells it to not render itself. Then they created a new t:radio component that renders a single radio button and its label wherever you place it. The t:radio has a "for" attribute that points back to the main selectOneRadio, and an "index" attribute that tells it which of the select items to output. It works with JSF's built-in AJAX and I love it. My only issue is that I can't use it in a ui:repeat loop, but I suspect that is a JSF spec issue related to findComponent. I'd also like to be able to choose if the label is rendered to the left or right of the radio button, or not render the label at all.

<t:selectOneRadio id="upgradesRadio" layout="spread" value="#

{model.upgradeSelection}

">
<f:selectItems value="#

{model.availableUpgrades}

" var="upgrade" itemLabel="#

{upgrade.description}

"/>
<f:ajax/>
</t:selectOneRadio>

... custom HTML layout ...

<t:radio for="upgradesRadio" index="0"/>

... custom HTML layout ...

<t:radio for="upgradesRadio" index="1"/>

Comment by rdelaplante [ 30/Aug/13 ]

Please PLEASE get this done in JSF 2.3, we've been waiting way too long for this. With a perfect solution in Trinidad that works well with the existing h:selectOneRadio design, I don' understand why this keeps getting left undone release after release. Search Google for people using JSF and radio buttons and you'll find a lot of misery.

Comment by rdelaplante [ 11/Jul/14 ]

I was working with the t:radio component from Trinidad recently and discovered an inflexibility. It always renders a label with the radio button and so I had difficulty implementing the layout and wrapping dictated by a web designer. Also, they wanted part of the label text to have different font styling. I was unable to embed any kind of HTML tags in the label text loaded from the backing bean (such as a span or div) because it always escapes the label text.

If you implement this feature in JSF 2.3 (please do!), it would be nice to have the option to output just the radio button without the label, and also the option to not escape the text in the label.

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by rdelaplante [ 19/Aug/15 ]

Another consideration for this component is the ability to bind the value to a Boolean. I've had numerous customers provide screen layouts with two radio buttons and specific wording that essentially boil down to yes/no or on/off, and I end up changing the wording to make it work with a checkbox instead. Some customers don't like that so I have to write backing bean code to read the value from the radio button component and store it in my model manually.

Comment by rdelaplante [ 25/Aug/15 ]

I'm monitoring the thread about this ticket on the JSF expert group mailing list but don't think I can reply to it so I'm posting my comments here. Specifically I'm commenting on Manfred's post about it being simple enough to register your own renderer and recommending that this ticket be closed as "Won't Fix". Also on Manfred's remark about a new component being overkill.

I created this ticket seven years ago and wrote most of the comments. I no longer recommend my original solution from the earliest comments. Instead I recommend the Tomahawk solution where they added a new value to the h:selectOneRadio layout attribute called "spread" which tells it to not render anything. They also created a new t:radio component which has a for attribute that points to the h:selectOneRadio component's id, and an index attribute to specify which SelectItem to use. IceFaces implemented the same solution.

Two component suites implemented the same solution which work well for me in my applications. It sounds like Manfred has a simpler idea. Can you please describe it?

As a developer who has been using JSF to create web applications for at least seven years now, I think that I am qualified to say that JSF does not currently and never has supported HTML radio buttons. The h:selectOneRadio component can only be used in trivial use cases which happens to be never, not even once, in all the years I've been using JSF. If it weren't for the Tomahawk and IceFaces solutions (crutches IMO) then developers like myself would not have been able to use JSF in our applications and wouldn't still be using JSF today.

Ed has asked me to volunteer to implement this. I've agreed to give it a shot but I really don't know the source code and would very much prefer that a real expert do it.

Comment by balusc [ 08/Aug/16 ]

I'll take it on me.

Comment by balusc [ 08/Aug/16 ]

Summarized: best approach would be to modify the existing renderer in such way so that at least the below cases are possible:

1:

<h:dataTable value="#{bean.items}" var="item">
    <h:column>
        <h:selectOneRadio group="foo" value="#{bean.selectedItem}">
            <f:selectItem itemValue="#{item}" />
        </h:selectOneRadio>
    </h:column>
</h:dataTable>

2:

<ui:repeat value="#{bean.items}" var="item">
    <h:outputLabel for="radioId" value="#{item.label}" />
    <h:selectOneRadio id="radioId" group="foo" value="#{bean.selectedItem}">
        <f:selectItem itemValue="#{item.value}" />
    </h:selectOneRadio>
    <br/>
</ui:repeat>

3:

<h:selectOneRadio group="foo" value="#{bean.selectedItem}">
    <f:selectItem itemValue="one" />
    <f:selectItem itemValue="two" />
    <f:selectItem itemValue="three" />
</h:selectOneRadio>
<h:selectOneRadio group="foo" />
<h:selectOneRadio group="foo" />

4:

<h:selectOneRadio group="foo" value="#{bean.selectedItem}">
    <f:selectItems value="#{['one', 'two', 'three']}" />
</h:selectOneRadio>
<h:selectOneRadio group="foo" />
<h:selectOneRadio group="foo" />

The group attribute is new. When group is specified, it must render solely a <input type="radio"> element (no table, no list). The group value must be relative to the UIViewRoot and represent the common HTML name.

If there are multiple components with same group in the UIViewRoot, then only the value and UISelectItem children of the first component are considered. Those of others are ignored and should issue a development stage warning. The UISelectItem values will be assigned to the components having same group in the same order as components appear in the UIViewRoot.

If the UISelectItem has a item label, then a <label> will be rendered directly after the <input> element, without any additional markup.





HTML5 Support (JAVASERVERFACES_SPEC_PUBLIC-1090)

[JAVASERVERFACES_SPEC_PUBLIC-1077] HTML5 Form Associated Elements Created: 22/Feb/12  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-990 HTML5 Forms Support Closed

 Description   

See: http://dev.w3.org/html5/spec/Overview.html#form-associated-element

The following elements, some of which already are rendered by JSF, have been updated or added for HTML5.

button
fieldset
input
keygen
label
meter
object
output
progress
select
textarea

Proper provision must be made for these in JSF 2.2



 Comments   
Comment by Frank Caputo [ 05/May/12 ]

It would be nice, if h:commandButton would render the button tag. Maybe we should have an optional attribute called "element" or "tag" which's value would be "button" to tell the renderer to render the children.
If we do so, we could simply render the value of the value attribute as a text child if no children are present, because the developer is used to use the value attribute for the button's text with classic buttons.

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major. Verify what needs to be done here.





[JAVASERVERFACES_SPEC_PUBLIC-1120] UIData (and related classes) doesn't respect contract for UIComponent process{Decodes, Validators, Updates} Created: 09/Jul/12  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jontyl Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A



 Description   

The javadoc descriptions in UIComponent for the abstract methods processDecodes, processValidators and processUpdates specifies: "Call the processX() method of all facets and children of this UIComponent, in the order determined by a call to getFacetsAndChildren()". UIData and other related components do not respect this.

Clearly, the problem is in the javadoc for UIComponent, which is much too restrictive.

This is important, firstly because obviously the spec should be self consistent, but also because it is very misleading when trying to understand how things fit together. The obvious place to look for information about what, in general, these methods do is the base class javadocs, but if this information is incorrect then from the start you are orientated in the wrong direction. This takes considerable effort to overcome.

Having a complete and accurate description of the responsibilities of the methods would, on the other hand, help understanding.



 Comments   
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.





[JAVASERVERFACES_SPEC_PUBLIC-1116] Add the possibility to change "rel" and "type" on <h:outputStylesheet> Created: 15/Jun/12  Updated: 11/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.1 Rev a
Fix Version/s: None

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

All


Attachments: Zip Archive spec-1116.zip    
Tags: css, outputStylesheet

 Description   

Currently, when using a <h:outputStylesheet>, it will always generate a <link href="..." rel="stylesheet" type="text/css">, there is no way to change the value of the "rel" and "type" attributes on the generated HTML tag.

But HTML5 is here and next technologies have emerged, like LESS, SASS ans SCSS. It would be cool to keep the actual default values but add "rel" and "type" attributes to the JSF component "outputStylesheet" so we can override them if needed.



 Comments   
Comment by paul_dijou [ 29/Oct/12 ]

To see the fact that "type" and "rel" are hard-coded, just check that source code: https://maven.java.net/service/local/repositories/releases/archive/com/sun/faces/jsf-impl/2.1.3/jsf-impl-2.1.3-sources.jar/!/com/sun/faces/renderkit/html_basic/StylesheetRenderer.java (it's near the end).

Not sure even the new passthru attributes can change them...

Comment by paul_dijou [ 13/Nov/12 ]

Also, consider the same problem with script resources. New types like Coffeescript are now possible. As we can see at the beginning of https://maven.java.net/service/local/repositories/releases/archive/com/sun/faces/jsf-impl/2.1.3/jsf-impl-2.1.3-sources.jar/!/com/sun/faces/renderkit/html_basic/ScriptRenderer.java , also here the type is hard-coded.

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.

Comment by Ed Burns [ 13/Aug/14 ]

I confirmed that this doesn't work, even with passthrough elements:

<h:outputStylesheet library="alibrary" name="favicon.ico" pt:rel="icon" pt:type="image/x-icon" />

Just outputs:

<link type="text/css" rel="stylesheet" href="/test-agnostic-renderKit-basic/faces/javax.faces.resource/favicon.ico?ln=alibrary" />

This clearly is not what is intended.





[JAVASERVERFACES_SPEC_PUBLIC-1112] Security bug with FacesContext in application startup Created: 01/Jun/12  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Configuration/Bootstrapping, Security
Affects Version/s: None
Fix Version/s: None

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


 Description   

Regarding the FacesContext that is available during application initialization, we need some language in the spec about how it is cleaned up. Otherwise, it can leak into the initialization thread of another application and allow one WAR to see the context of another WAR.

Also, we need some language saying that FacesContext.getCurrentInstance() should always return null except when:
A) We are in the context of a servlet request, or
B) We are receiving a PostConstructApplicationEvent

See http://java.net/jira/browse/JAVASERVERFACES-2436 for full details and an application that recreates the issues.



 Comments   
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.





[JAVASERVERFACES_SPEC_PUBLIC-1093] The id attribute of javax.faces.ViewState is not unique Created: 01/May/12  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2 Sprint 12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dmsinotte Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any


Attachments: Zip Archive viewstate.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-790 javax.faces.ViewState + PPR does not ... In Progress

 Description   

As per the work done for this spec change, http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-220, the id of each hidden ViewState element is supposed to be unique on the page. This should hold true for multiple forms in a single view as well as multiple views on the page (e.g. portlets). The documentation in ResponseStateManager indicates that this should be done by setting the id to be:

namingContainerId:javax.faces.ViewState:counterUniqueToView

I have attached a test case which has two forms on it. The resulting ViewState elements both have identical ids:

ViewState for form1: j_id1:javax.faces.ViewState:0
ViewState for form2: j_id1:javax.faces.ViewState:0

The counter is not incremented and the id of the form (which should be the naming container in this case) is not used.

Also, I noticed that the method for getting the ViewState id is com.sun.faces.util.Util.getViewStateId(FacesContext fc). For those of us working on extending the framework who might need access to the information in their own renderers, will there be a way to get at the information in a more public way?



 Comments   
Comment by tedgoddard [ 03/May/12 ]

(First of all, javax.faces.ViewState should not be modified for Ajax updates using server-side state-saving, but this simple approach does not appear to be the current direction.)

We are a bit unclear on how the current implementation is intended to work, but expect that something like the following is necessary:

When the request is submitted, call getElementsByName('javax.faces.ViewState') and store the list of IDs for all with equal value to that of the javax.faces.ViewState in the submitting form. In the case of future JSP inclusion or current Portlets, there will be javax.faces.ViewState fields not associated with the current view. They will have different values and are not included in the list.

When the partial response is generated, it may contain rendered hidden inputs with name javax.faces.ViewState and unique IDs, but also contains the special case <update id="javax.faces.ViewState"><![CDATA[...]]></update>. The previously stored list of IDs are now all updated to use the new value. Any javax.faces.ViewState hidden fields that have been modified by the page update itself (potentially now having different IDs) have the correct value anyway because they were just updated.

Comment by Ed Burns [ 03/May/12 ]

TG> (First of all, javax.faces.ViewState should not be modified for Ajax
TG> updates using server-side state-saving, but this simple approach
TG> does not appear to be the current direction.)

Can you please elaborate more on what you mean by this? The issue
doesn't mention anything about Ajax specifically. Is this a separate
concern you are raising, Ted?

TG> We are a bit unclear on how the current implementation is intended
TG> to work, but expect that something like the following is necessary:

TG> When the request is submitted, call
TG> getElementsByName('javax.faces.ViewState') and store the list of IDs
TG> for all with equal value to that of the javax.faces.ViewState in the
TG> submitting form. In the case of future JSP inclusion or current
TG> Portlets, there will be javax.faces.ViewState fields not associated
TG> with the current view. They will have different values and are not
TG> included in the list.

TG> When the partial response is generated, it may contain rendered
TG> hidden inputs with name javax.faces.ViewState and unique IDs, but
TG> also contains the special case <update
TG> id="javax.faces.ViewState"><![CDATA[...]]></update>. The previously
TG> stored list of IDs are now all updated to use the new value. Any
TG> javax.faces.ViewState hidden fields that have been modified by the
TG> page update itself (potentially now having different IDs) have the
TG> correct value anyway because they were just updated.

These two comments are better suited to JAVASERVERFACES_SPEC_PUBLIC-790,
so I'll copy them there. Ted, can you please take a look at 790 and see
if you agree that your comments pertain more to that issue than this
one?

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major. Verify if we are already doing the right thing.





[JAVASERVERFACES_SPEC_PUBLIC-951] Unable to map composite component facet to new name Created: 23/Mar/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0, 2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: kenpaulsen Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day
Environment:

All


Status Whiteboard:

size_small importance_large


 Description   

If you need to map map the public name exposed by a composite component to a different name as required by the consuming component, it is not possible with cc:insertFacet. Here's an example:

Page:
<my:component>
<f:facet name="fooHeader">
<h:outputText value="foo" />
</f:facet>
<f:facet name="barHeader">
<h:outputText value="bar" />
</f:facet>
</my:component>

Component:
<cc:implementation>
...
<h:dataTable ...>
<cc:insertFacet name="fooHeader" />
...
</h:dataTable>
<h:dataTable ...>
<cc:insertFacet name="barHeader" />
</h:dataTable>

In the example component code above "header" is the required name for h:dataTable. However, to retrieve the outer name, you must use the correct name exposed by the component, "fooHeader" or "barHeader" in this example. The above code will obviously fail to render the headers.

To solve this, I propose adding "localName" (or something similar) to the insertFacet tag:

<cc:insertFacet name="barHeader" localName="header" />

Thanks!

-Ken



 Comments   
Comment by persapiens [ 06/Nov/11 ]

I have problem to create composite components using cc:renderFacet inside a p:datatable

Page:

<sds:crud>
<f:facet name="listColumns" >
<p:column >
<f:facet name="header">
My column
</f:facet>
<h:outputText value="#

{s}

" />
</p:column>
</f:facet>
</sds:crud>

My Component (crud):

<cc:interface >
<cc:facet name="listColumns" required="true" />
</cc:interface>

<cc:implementation>
<p:dataTable value="#

{teste.list()}

" var="s">
<cc:renderFacet name="listColumns" />
</p:dataTable>
</cc:implementation>

If I use cc:insertChildren it works, however I need to use facets.

Comment by Manfred Riem [ 13/Feb/12 ]

Ken,

Have you tried doing the following?

<cc:implementation>
<h:dataTable>
<f:facet name="header">
<cc:renderFacet name="fooHeader"/>
</f:facet>
</h:dataTable>
</cc: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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-935] UIData needs review on a couple of fronts Created: 31/Jan/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Σ Remaining Estimate: 3 days, 23 hours, 30 minutes Remaining Estimate: Not Specified
Σ Time Spent: 1 hour, 16 minutes Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-322 Add interfaces to javax.faces.compone... Sub-task Open  
JAVASERVERFACES_SPEC_PUBLIC-479 UIData should support the collection ... Sub-task Closed Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-963 Alignment/extending of iterating ui c... Sub-task Open  
JAVASERVERFACES_SPEC_PUBLIC-965 Provide a component for iterating ove... Sub-task Open  
Status Whiteboard:

size_medium importance_medium


 Description   

Note that the following will most likely apply to 1.2 as well

From Martin Marinschek:
-----------------------------

a) if invokeOnComponent returns successfully for any of the facets,
invokeOnComponent should return with true - currently it doesn't (maybe there is
a reason for this I fail to see?)

b) I think that the NumberConversionException thrown from the current version of
this method is dangerous in the sense that if the client-id is not actually
valid (the component is not yet anymore in the table) but was a sub-component of
a naming-container in a facet (client-id
tableClientId:namContainerId:subCompId), the long client-id will trigger the
code to check if the component is in one of the rows and you will suddenly get a
number conversion exception popping up from the table. This is not the case with
other components and invokeOnComponent, and so should be done differently.
Instead, this NumberConversion exception has to be silently ignored - or a
better solution for this algorithm has to be found (I didn't find one in a
decent time-frame, however, and just ignored the NumberConversion exception in
my version).

As a side-note: could it be that you guys keep track of the state of children of
transient nodes? I seem to be running into this from time to time. Leonardo
mentioned this as an implementation difference to MyFaces to me, so maybe you
could check if this is the case (I don't think this would make sense - a
transient component would certainly mean every sub-component has to be transient
as well).



 Comments   
Comment by lu4242 [ 18/Apr/11 ]

The most important problem I see with UIData current implementation is the clientId append the rowIndex and it could be better if we can just create some property called rowKey or a converter or whatever that allow us to generate this part of the id in a clean way. Right now, there is a solution for this one committed on tomahawk code if you want to take a look. I'm willing to write the solution for mojarra too.

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-925] Helper methods for FacesContext Created: 31/Jan/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Status Whiteboard:

size_small importance_medium


 Description   

There are a number of fairly common tasks for web applications that require a
fairly long method string to capture. A set of helper methods would be handy...

For instance getting a parameter, or getting an EL value, both require chained
method calls that are 5 levels or so deep. There are probably others - I'll
think about it and see if I can come up with a list.



 Comments   
Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all of Sheetal's spec issues to me.

Comment by arjan tijms [ 08/Aug/11 ]

This would be really handy. The FacesContext not only requires deep chaining, but since especially ExternalContext doesn't make too many assumptions about its environment (basically a Good Thing) a lot of casting is typically done in web applications.

Since Servlet based web applications seem to be the most common use case for JSF, a (additional) utility class could be created that already assumed this environment. Many JSF applications that I've seen already create such utility classes anyway. Besides the mentioned helper methods, the following might be useful:

  • HttpServletRequest getRequest()
  • HttpServletResponse getResponse()
  • HttpSession getSession()
  • Map<String, String> getRequestParameterMap()
  • ServletContext getServletContext()
  • Locale getLocale()
  • UIComponent findComponent(String expression)
  • addPhaseListener(PhaseListener phaseListener)
  • <T> T evaluateExpression(String expression)

And finally two (perhaps) more exotic helper methods:

  • void addBeforePhaseListener(PhaseId phaseId, final Runnable runnable)
  • void addAfterPhaseListener(PhaseId phaseId, final Runnable runnable)

The last two not only flatten the FacesContext chain, but allow a single interface type (SAM type) to be a PhaseListener, which is already more convenient to implement but will ever further reduce complexity when/if Java 8 closures are introduced. It can be implemented by simply adding some DefaultPhaseListener that calls the provided Runnable:

public static void addAfterPhaseListener(PhaseId phaseId, final Runnable runnable) {

    FacesContext.getCurrentInstance().getViewRoot().addPhaseListener(new DefaultPhaseListener(phaseId) {

        @Override
        public void afterPhase(PhaseEvent event) {
            runnable.run();
        }
    });
}

Not sure if it's in scope for this issue, but some helper methods for components would also be nice. Some tasks that you'd think would be simple, still require some amount of code. E.g.:

  • boolean hasValue(UIInput input) // without firing validators
  • <T> T getValue(UIInput input) // validated value, without need to know if validation already happened before call
  • String getComponentLabel(UIComponent component)
Comment by Ed Burns [ 09/Aug/11 ]

I've added this issue to the JSF_2_2_WORKING_SET JIRA filter.

Comment by arjan tijms [ 15/Oct/11 ]

Another simplification that could be caught in a single method is adding faces messages.

Currently, idiomatic code to adding such a message (globally) is this:

FacesContext context = FacesContext.getCurrentInstance();
FacesMessage message = new FacesMessage("Error message here");
message.setSeverity(FacesMessage.SEVERITY_ERROR);
context.addMessage(null, message);

It gets more verbose when i18n is involved:

FacesContext context = FacesContext.getCurrentInstance();
Locale locale = context.getViewRoot().getLocale();
String bundleName = context.getApplication().getMessageBundle();
ResourceBundle bundle = ResourceBundle.getBundle(bundleName, locale);
String text = null;
try {  
    text = MessageFormat.format(bundle.getString(key), param1, param2);
} catch (MissingResourceException e) {
    text = "Missing key: " + key;
}
FacesMessage message = new FacesMessage(text);
message.setSeverity(SEVERITY_ERROR);
context.addMessage(null, message);

Every JSF project in practice that I've seen thus abstracts this code away in some utility method. For instance, the following captures a great chunk of practical usage:

FacesMessages.addMessageFromBundle(SEVERITY_ERROR, key, param1, param2);

(incidentally, this was one of the original gripes Matt Raible had with JSF: http://raibledesigns.com/rd/entry/the_joy_of_developing_with)

Several variants are possible (but to keep it simple, not too many variants should be introduced, else the user is better of using the existing API).

Don't look up in bundle, but use text provided by user:

FacesMessages.addMessage(SEVERITY_ERROR, text, param1, param2); 

Overloaded to add message to specific component:

FacesMessages.addMessage(componentId, SEVERITY_ERROR, text, param1, param2);
Comment by arjan tijms [ 28/Dec/11 ]

One more request for a helper method, although it's more related to components so I'm not sure it's in scope for this ticket, but it's a method to get hold of all select items for a given component.

Currently almost everybody seems to be creating their own version of this (e.g. Mojarra's com.sun.faces.renderkit.SelectItemsIterator, MyFaces' org.apache.myfaces.shared_impl.util.SelectItemsIterator and PrimeFaces' org.primefaces.util.ComponentUtils#createSelectItems).

Comment by tedgoddard [ 21/Feb/12 ]

Implementation for a given helper method is likely straightforward, but some may be controversial. For instance, getRequest() (as above) is only valid in a Servlet environment. Not all application code requires Servlet/Portlet portability, so potentially a helper with a type-safe API could be instantiated and used:

helper = new FacesServletHelper(facesContext)

but perhaps a better question is why direct access to the HttpServletRequest is required. Once this is understood, type-safe portable methods could potentially be added to FacesContext or ExternalContext.

Comment by arjan tijms [ 21/Feb/12 ]

Not all application code requires Servlet/Portlet portability, so potentially a helper with a type-safe API could be instantiated and used:

That was indeed exactly what I meant with "Since Servlet based web applications seem to be the most common use case for JSF, a (additional) utility class could be created that already assumed this environment."

but perhaps a better question is why direct access to the HttpServletRequest is required

A quick scan in the JSF application I build with my team reveals that among others this is used to access the request attributes, to get a specific request header, interaction with legacy/non-jsf code that requires the HttpServletRequest as input, getting the userPrincipal or doing the isUserInRole check.

Clearly, a lot on that on that list is also available on the type-safe ExternalContext.

Comment by kithouna [ 28/Jan/13 ]

@tedgoddard what about HttpServletRequest#login, logout, authenticate etc?

Comment by kito75 [ 27/Jun/14 ]

The OmniFaces FacesLocal class is a good reference for this: http://showcase.omnifaces.org/utils/FacesLocal;

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1002] Order of isRendered and pushComponentToEL prevents rendered="#{}" based on component implicit object Created: 17/May/11  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Martin Kočí Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Current specification for lifecycles methods:
1) processDecodes
2) processValidators
3) processUpdates
4) encodeAll
4) encodeBegin

explicitly says that:

1) If the rendered property of this UIComponent is false, skip further processing.
2) call pushComponentToEL

But in that order of invocations it is impossible to achieve rendered like this:

<h:outputText rendered="#

{component.id eq 'outputTextId'}

" id="outputTextId" />

i.e. any rendered ValueEpression based on component itself.



 Comments   
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.





[JAVASERVERFACES_SPEC_PUBLIC-988] Dynamic include problem Created: 25/Apr/11  Updated: 12/Aug/14

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

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

Status Whiteboard:

size_large importance_large


 Description   

JB> 2) the "dynamic UI include" problem - This is a scenario where you
JB> have several different types of include files and need to show a
JB> list of items (each "item" being the include template) where the
JB> list is only know at runtime. Let's make up a specific example here
JB> to illustrate:

JB> You have an event registration system that sells tickets online:

JB> - A user can buy multiple tickets (and different types of tickets)
JB> as part of the purchase process

JB> - Each ticket purchased has to have totally different information
JB> filled out

JB> - There are many different types of tickets (e.g.: attendee,
JB> sponsor, exhibitor, etc)

JB> - every time they "add a ticket" (it considers what kind of ticket
JB> they selected and adds that type of form to the list of forms that
JB> will need to be completed before proceeding with the purchase)

JB> Now obviously in this example you could build a "dynamic" template
JB> that based on an input variable renders itself differently and put
JB> this inside a <ui:repeat/> - or for that matter you could
JB> programmatically insert the elements comprising each type of form
JB> into the control tree. The problems with these approaches is that
JB> you're back to server programming for every little UI change (not to
JB> mention you've got one big component with potentially hundreds of
JB> pieces of logic in it). ASP.NET solves this by allowing you to
JB> define a .ascx file (much like a facelet include) and then
JB> programmatically include them into something akin to a JSF
JB> panelGroup. Then on postback you simply get an enumeration of the
JB> items and loop through them to retrieve the values of the class
JB> that's bound to the child components. Now with a lot of trickery and
JB> a ton of time for each implementation you can get something close
JB> with JSF but it's not at all intuitive or easy.



 Comments   
Comment by lamine_ba [ 26/Apr/11 ]
  • The JSF framework is a set of abstractions for building different types of web applications.
  • A business application is a set of polymorphic systems.
  • Different types of Customers
  • Different types of Contracts
  • Different types of Y

which leads to this recurrent design

public abstract class Y {
}


public class XY extends Y{
}

which once applied in an event registration system brings something like this

public abstract class Ticket {         
}


public class SponsorTicket extends Ticket {
}


public class AttendeeTicket extends Ticket {
}


public class Reservation {

      public void addTicket(Ticket ticket) {
      }         
      public void removeTicket(Ticket ticket) {
      }
      public Collection<Ticket> getTickets() {
      }
 }

Let's make something interesting now and let's override the toString() method to return the type of a ticket.

public class SponsorTicket extends Ticket {
        
     public String toString() {
            return "SponsorTicket";
     }
}


public class AttendeeTicket extends Ticket {

      public String toString() {
             return "AttendeeTicket";
       }

}

This technique is powerful in a polymorphic system once coupled with the power of a template engine to generate dynamic content following a pattern like this one :

             return-value${dynamic-value}
             
  • Let's design now our form web pages using the Velocity Template Engine
  • Reservation page

dynamic include of the derivate forms based on the toString() return value.

   #foreach($ticket in $reservation.tickets)
    #set($template="form" + $ticket + ".vm")         
    #include($template)
   #end
  • formSponsorTicket.vm
label 1 : <input type="text" value=".."/>
label 2 : <input type="text" value=".."/>
label 3 : <input type="text" value=".."/>
label 4 : <input type="text" value=".."/>
label 5 : <input type="text" value=".."/>

Because we have a polymorphic system, the forms will have some fields in common. Thus to avoid the duplication, it is better to create a common page (formTicket.vm) like we did for the abstract class Ticket.

#foreach($ticket in $reservation.tickets)
      #include("formTicket.vm")                                                
      #set($template="form" + $ticket + ".vm")
      #include($template)
#end

..............................................................................

  • Let's design now our form web pages using the Facelets Template Engine
  • Reservation Page

<ui:repeat value="#{reservation.tickets}" var="ticket">
       <ui:include src="formTicket.xhtml"/>                 
       <ui:include src="form${ticket}.xhtml"/>                 
</ui:repeat>

Common Page : formTicket.xhtml


label 1 : <h:inputText  value=".."/>
label 2 : <h:inputText  value=".."/>

Page : formSponsorTicket.xhtml


label 3 : <h:inputText  value=".."/>
label 4 : <h:inputText  value=".."/>
label 5 : <h:inputText  value=".."/>

-------------------------------------------------------------------------

Comparison of the solutions

The two solutions are the same even if I'm using two different template engines and what is quite amazing is that none of them works. Why? Because when you include a file in a iteration, you still get the whole context as model. No way to use the current object being iterated as model thus making you unable to do something like this

<ui:repeat value="#{reservation.tickets}" var="ticket"> 
    <ui:include src="formTicket.xhtml"/> (var="ticket" not used)
    ....................................................
</ui:repeat>

Velocity :

<input type="text" value="${ticket.property1}"/>

Facelets :

 <h:inputText  value="#{ticket.property1}"/>

Jason, You are doing a binding in your managed beans because you want to have a way to get this reference and as you may know, binding means coupling, maintenance nightmare, a change here and a change there.

To overcome this problem without using the problematic programmatic approach, we should have a way to set the model to use for the template to be included, something like this

 <ui:include src="formTicket.xhtml" model="${ticket}"/>

Reservation Page


<ui:repeat value="#{reservation.tickets}" var="ticket">
     <ui:include src="formTicket.xhtml"    model="#{ticket}"/> 
     <ui:include src="form#{ticket}.xhtml"  model="#{ticket}"/>
</ui:repeat>

Another alternative would be to use the JSF composite components feature which is the opposite side of the dynamic include approach
and one possible solution to leverage if the JSF runtime was able to generate dynamically the xml tags by following a pattern like this

  <namespace:#{tag-value}>

So instead of creating a facelets view for each type of ticket, we will create a composite component for each type of ticket and write something like this in the reservation page

Reservation Page

<ui:repeat value="#{reservation.tickets}" var="ticket">
    <ez:formTicket    model="#{ticket}"/>   (formTicket.xhtml)
    <ez:form#{ticket}  model="#{ticket}"/>  (formSponsorTicket.xhtml...)
</ui:repeat>

Composite component (formSponsorTicket.xhtml)

<composite:interface>
    <composite:attribute name="model" required="true"/>
</composite:interface>

<composite:implementation>

    label 3 : <h:inputText  value=" #{cc.attrs.model.property1}"/>
    label 4 : <inputText  value="#{cc.attrs.model.property2}"/>
    label 5 : <inputText  value="#{cc.attrs.model.property3}"/>

</composite:implementation>

If the dynamic tags generation is impossible for JSF, we can still make some if.........

<ui:repeat value="#{reservation.tickets}" var="ticket">
      <c:if test="#{ticket == 'SponsorTicket'}">
         <ez:formSponsorTicket    model="#{ticket}"/>.
       </c:if>
           ......
</ui:repeat>

we have two solutions and two possible new issues.

1) Facelets inclusion improvement
2) EL support for generating dynamic xml tags

These solutions have been realized from a page author perspective.

Comment by lamine_ba [ 27/Apr/11 ]

JB> Proposed solutions certainly appear valid – but this may actually be a little easier. If item 989 (http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-989) is implemented you could quite simply use that function to programmatically add the dynamic include to the control tree. This of course assumes that you can read, compile and include a facelet file programmatically (which I believe I’ve seen somewhere?)

MLB> Again Jason, thus you can programmatically create an UI representation for your object and attach this representation to its UI container
But this time the UI representation is not created directly from your java code. You take it from a resource, from a facelets file written maybe by a web designer. And the algorithm of your handleRepeatItem(Object currentObjectFromCollection, UIComponent currentContainerHoldingChildComponents) method will look something like that:

1)for the currentObjectFromCollection, find its UI resource file (facelets file)
2) load the resource file, compile it and create an UI representation from it
3) Attach the UI representation to its UI container : currentContainerHoldingChildComponents.add(representation)

But at this point, If I were you, I would say " Hey I don't see anymore what JSF did for me and the abstraction it brings to ease the job. Why do I have my hands dirty? Why things shouldn't be simpler as to give the resource name to the JSF runtime which will manage the details for me and create an UI representation (UIComponent) from my resource ".

javax.faces.Application class


public abstract class Application {

 public UIComponent createComponent(FacesContext context,
                                       Resource componentResource) {
}

public UIComponent createComponent(Resource resource) {
  // a simplification of the first method which use the current context

}


public UIComponent createComponent(String resourceName) { 

 // unification, componentType and resourceName must be supported

}

}

To move further Take a look at these issues below because they are related

Where to find the resources : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-809

Jason, you are managing 40 developers to develop business applications? Are these applications modular? How do you divide the work among your developers? How do you do the integration of the pieces (modules)? How do you reuse your past work when developing a new application? Do you always start from scratch?

Support for modular, reusable fragments of web applications : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-532
Plugin System : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-970

Have you a web designer in your team?

Multi-templating : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971

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.





UIData needs review on a couple of fronts (JAVASERVERFACES_SPEC_PUBLIC-935)

[JAVASERVERFACES_SPEC_PUBLIC-963] Alignment/extending of iterating ui components Created: 01/Apr/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.2
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: Mathias Werlitz Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_small


 Description   

UIRepeat and UIData do pretty much the same: iterate over a collection of items. There should be a common base class for this, encapsulating the complicated logic for saving/restoring and iterating the state of the "rows". Something like "UIIterate".

Writing iterating components is very complicated at the moment. This base class should be easy to extend and also support any kind of data structures, not only "lists". Using an integer for the "row" iterating index is insufficient for creating "tree" components. A string or kind of indexing object would be much more flexible.

UIRepeat and UIData could extend this class and provide the existing interface on top of it.



 Comments   
Comment by Mathias Werlitz [ 21/Apr/11 ]

Well the essential difference between UIData(<h:dataTable>) and UIRepeat is how the iteration is done during render response.
UIRepeat iterates in the component and HtmlDataTable iterates in the renderer. This flexibility should be possible. Iterating in the renderer can be easier for "tree" components.

I could imagine a structure like this:

UINamingContainer
|
UIIterate
|
|- UISequentialIterate
| |
| |- UIData
| |- UIRepeat
|
|- UITree?

At least there should be an marking interface for such components because state saving seems to be different when nesting of iterating components is possible. For example UIRepeat already checks for UIData or UIRepeat parents. UIData does only look for itself as a parent.

Comment by Ed Burns [ 22/Apr/11 ]

I thought we had an issue for this, but yes, it's a good idea.

Comment by arjan tijms [ 27/Mar/14 ]

I think is a very important issue. In general UIData seems to be more robust than UIRepeat, but they indeed do pretty much the same thing and when inspecting the code it also looks like they had similar implementations at one time and/or borrowed from each other.

If there was a common implementation bugs such as JAVASERVERFACES-3215 would probably not have been there.

It would also prevent issues like JAVASERVERFACES_SPEC_PUBLIC-1103. In that case UIData got a new feature that UIRepeat would have needed just as well, but because of the time between JSF releases now has to wait for this for a rather long time.

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-961] Limited layout of SelectManyCheckbox and SelectOneRadio Created: 01/Apr/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Mathias Werlitz Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File screenshot-1.jpg    
Status Whiteboard:

size_large importance_small


 Description   

<h:selectManyCheckbox> and <h:selectOneRadio> are very limited regarding the output and layout of the individual items. For example is not possible to output any further description for the items. Furthermore rendering tables for layout is quite old fashioned.

Sine these are base components and used very often they should be improved to support user defined output like MyFaces tomahawk eliminating the need for additional component libraries.



 Comments   
Comment by Ranger [ 28/Apr/11 ]

It would be very nice to be able to make design like this with use of <h:selectManyCheckbox>

<h:selectManyCheckbox> use of tables make it impossible.

I think this issue should have a higher priority.

I have meet limiteations of the <h:selectManyCheckbox> and <h:selectOneRadio> several times.

And made work around using <h:inputHidden>, <input type="checkbox"> and JavaScript to transfer values from checkboxes and radio buttons to the <h:inputHidden> to use them in JSF.

Comment by rdelaplante [ 11/Jul/14 ]

+1

I wonder if this is related to JAVASERVERFACES_SPEC_PUBLIC-329

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-810] Access to component ancestor chain during Facelets handler processing Created: 25/May/10  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: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 810
Status Whiteboard:

size_large importance_medium

Tags: adf

 Description   

We have various JSP tag implementations that walk up the component ancestor chain during tag execution
for one reason or another. While porting these tags to Facelets, we have been forced to work around the
fact that Facelets does not connect the ancestor chain until after children have been processed.

While it may be too late to change Facelets behavior now, it would be helpful to provide access to the
ancestor chain through some API so that Facelets handlers can interact with parent/ancestor components.



 Comments   
Comment by Ed Burns [ 27/May/10 ]

2.1.

Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

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.





[JAVASERVERFACES_SPEC_PUBLIC-795] UIViewParameter state saving algorithm Created: 12/May/10  Updated: 01/Aug/14

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

Type: Bug Priority: Major
Reporter: Jakob Korherr Assignee: Unassigned
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 795
Status Whiteboard:

size_small importance_medium


 Description   

From the mail "State saving of UIViewParameter" on jsr-314-open:

UIViewParameter uses the submittedValue to store its value in the state for the
next postback, because obviously the view parameter won't be in the request
parameter map of the next request (which is the postback). But because its
submittedValue is null after the conversions and validations, it has to be set
again before the state is generated. To accomplish that, the spec currently
states to override encodeAll() and make the call to setSubmittedValue() there.
In addition, encodeAll() has to be called in UIViewRoot.encodeEnd() for every
UIViewParameter in the view. This works perfectly for normal requests, but when
you are using an AJAX request the state is generated before
UIViewRoot.encodeEnd() is called an thus the submittedValue for every
UIViewParameter is null in the state. This means that the value of every
UIViewParameter will be null in the following request.

Now the easiest solution to this problem, which I also already committed to
MyFaces trunk (again see [1] for details), is to do mostly the same as in
UIViewRoot.encodeEnd() just also in PartialViewContext.
processPartial() when the PhaseId is RENDER_RESPONSE before the state is
generated to make it work for AJAX-requests.

However I don't really like this solution, because we have to think of handling
UIViewParameters in a special way every time we change something on any render
mechanism. Why don't we just override saveState() on UIViewParameter and set the
submittedValue there before the state is saved. This will have the same result,
but without the code in UIViewRoot, PartialViewContext and
UIViewParameter.encodeAll() and without future headaches. I also already
uploaded a patch for this to the MyFaces issue at [1].

Answer to this from Martin Marinschek: "This is just a so much better solution
. We should spec this one."

[1] https://issues.apache.org/jira/browse/MYFACES-2645



 Comments   
Comment by Ed Burns [ 17/May/10 ]

Move to 2.1.

I agree with this approach.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by kithouna [ 28/Feb/13 ]

Was anything ever done for this one?

Comment by nullone [ 28/Feb/13 ]

Myfaces team took 3 days to review and accept the fix, and Mojarra team could not do the same thing for more than 33 months, and still saw no light.

Is that really amazing or the team is sleeping on its way?

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Set priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-723] add partial parameter Created: 19/Jan/10  Updated: 01/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 723
Status Whiteboard:

size_small importance_large


 Description   

add attribute partialSubmit="true/false" to f:ajax and
parameter partialSubmit:'true/false' to jsf.ajax.request options

Only the components named in the "execute" parameter are processed in phase 2-4,
but the spec insists on submitting all elements included in a form. If
partialSubmit is set to true submission is reduced to the form params named in
execute. This is a performance feature that can boost speed on large pages.



 Comments   
Comment by ganeshpuri [ 19/Jan/10 ]

Set target milestone to 2.1

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 29/Jun/10 ]

status whiteboard

Comment by rogerk [ 29/Jun/10 ]

target milestone

Comment by ganeshpuri [ 30/Jun/10 ]

Former name: "partialSubmit", but "partial" is more compact.
Would be great to get this into JSF 2.1

Comment by rogerk [ 13/Sep/10 ]

unfortunately this will go into 2.2

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by tedgoddard [ 21/Apr/11 ]

This is a very good feature provided that there is also a "whitelist" of additional parameters that must be submitted with every Ajax post. Alternatively, a JavaScript callback could be registered to allow frameworks to add required parameters to the POST before submission.

Comment by Ed Burns [ 25/Apr/11 ]

Regarding the whitelist, we do have that already as documented in the JSDoc.

I strongly favor the callback option. We already have a function jsf.getViewState(formElement). We could specify that a user provided function is called before returning from getViewState() that takes the associative array and the function can modify the associative array however they like.

Comment by arjan tijms [ 13/Nov/11 ]

MyFaces seems to have implemented this and calls it Partial Page Submit (PPS). Werner Punz recently blogged about this great feature here: http://werpublogs.blogspot.com/2011/07/apache-myfaces-jsfjs-queue-control.html

Incidentally, JavaServer Faces 2.0 The Complete Reference already spoke about a "Partial Submit" (page 343 "... only the value of the userid field is submitted" and Figure 12-2, page 345).

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-715] missing <f:behavior> (convenience) tag Created: 05/Jan/10  Updated: 01/Aug/14

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

Type: Bug Priority: Major
Reporter: mwessendorf Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 715
Status Whiteboard:

cat2 javadoc size_medium importance_large draft


 Description   

For converters/validators there is a convenience tag to integrate (simple)
custom implementations of these.

For behaviors that is not the case. A <f:behavior> tag would nice; It should
"act" similar to its cousins, f:converter/validator



 Comments   
Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

vdl

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 ]

edburns

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 [ 10/Sep/10 ]

Move these to 2.2

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Set priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-704] UIRepeat et al are not specified Created: 16/Dec/09  Updated: 12/Aug/14

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

Type: Bug Priority: Major
Reporter: mwessendorf 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: All


Issuezilla Id: 704
Status Whiteboard:

cat2 javadoc size_medium importance_large draft


 Description   

with JSF 2.0, thanks to Facelets, there is a <ui:repeat>. While I understand
that tags/rendering behavior is part of the internals of an implementation, I am
not really sure if the underlying/related components should be "hidden" by the
spec as well.

For instance: I noticed that in MyFaces the UIRepeat extends UIComponentBase and
implements NamingContainer, while with the JSF RI / Mojarra, the UIRepeat "just"
extends the UINamingContainer...

... and oh yes... I know that UINamingContainer extends UIComponentBase and
implements NamingContainer....

but instanceof UINamingContainer doesn't say TRUE for the MyFaces UIRepeat

See a community related discussion here:
http://markmail.org/message/wllfudu4ge7n5gxa



 Comments   
Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

javadoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by Ed Burns [ 19/Jul/10 ]

https://glassfish.dev.java.net/issues/show_bug.cgi?id=11785

On Mon Apr 12 15:57:00 +0000 2010, mohammadalavi MA wrote

MA> I've found 2 bugs in jsf 1.2 here's the list
MA>
MA>
MA> 1.when h:dataTable's parent is ui:repeat from facelet duplicated ids
MA> are generated for child component because UIData's
MA> isNestedWithinUIData method reports true
MA> only when the parent is an instance of UIData and UIRepeat is not.
MA> of course the problem happens because the UIData's getClientId method
MA> caches the parent client id when isNestedWithinUIData returns false
MA> if it never cache parent client id this problem wont happen.
MA>
MA> public String getClientId(FacesContext context) {
MA> if (context == null)

{ MA> throw new NullPointerException(); MA> }

MA> if (rowIndex >= 0)

{ MA> String cidBuilder = new StringBuilder(); MA> return cidBuilder.append(super.getClientId(context)) MA> .append(NamingContainer.SEPARATOR_CHAR).append(rowIndex) MA> .toString(); MA> }

else

{ MA> return super.getClientId(context); MA> }

MA> }
MA> 2.TableMetaInfo a static inner class in BaseTableRenderer is used for
MA> managing style for columns and rows, the getCurrentColumnClass method
MA> doesn't work as expected it doesn't repeat the styles when number of
MA> columns is grater than column classes it should be implemented as
MA> follows:
MA>
MA> public String getCurrentColumnClass() {
MA>
MA> String style = null;
MA> if (columnStyleCounter < columnClasses.length &&
MA> columnStyleCounter < columnCount)

{ MA> style = columnClasses[columnStyleCounter++]; MA> }

MA> if(columnStyleCounter >= columnClasses.length)

{ MA> columnStyleCounter = 0; MA> }

MA> return ((style != null && style.length() > 0) ? style : null);

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

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.





[JAVASERVERFACES_SPEC_PUBLIC-682] Add support for XHR timeout Created: 02/Dec/09  Updated: 12/Aug/14

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

Type: Bug Priority: Major
Reporter: driscoll 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: All


Issuezilla Id: 682
Status Whiteboard:

size_large importance_large


 Description   

Add support for XHR timeout.

This is marked as a P1 spec defect - it was felt during the EG Ajax meeting that
this lack of support for timeout was a critical failure.

A request that is unexpectedly long running, or a network timeout, can
completely freeze the client. Hence, the P1 status.



 Comments   
Comment by ganeshpuri [ 21/Jan/10 ]

corrected target

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 28/Jun/10 ]

target 2.1_gf31_m5

Comment by rogerk [ 03/Sep/10 ]

starting

Comment by rogerk [ 03/Sep/10 ]

I am looking to introduce a "timeout" attribute (property) on the ajax.request
(and also f:ajax tag) where u can specify a time in milliseconds. For example:

onclick="jsf.ajax.request(this, event,

{execute: this.id, render: 'out1', timeout: '5000'}

);....

and also

f:ajax timeout="5000"...

Comment by rogerk [ 13/Sep/10 ]

target MS6

Comment by rogerk [ 20/Sep/10 ]

Out of time for this for 2.1.

Comment by werpu12 [ 06/Mar/12 ]

MyFaces has timeout already in with a custom parameter.
You cam pass a myfaces

{timeout:<value>}

in the options list.

The timeout should be an option like execute and render.

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.





[JAVASERVERFACES_SPEC_PUBLIC-674] Allow ajax response short-circuit/override Created: 20/Nov/09  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 674
Status Whiteboard:

cat2 frame size_medium importance_medium


 Description   

Currently, JSF handles an ajax response, including the re-rendering of the
specified components, every time, even if onevent is specified. There are times
when the ajax response requires custom handling. For example, the HTML returned
after rerendering a large data table might need to be passed to a Javascript
widget so it can update its state in a widget-specific manner. There is
currently no way to do this.

I would like to see the ajax portion of the spec modified to allow client code
to override the response handling, thus assuming the full burden of updating the
client.



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

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

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.





[JAVASERVERFACES_SPEC_PUBLIC-658] PartialViewContext interoperability Created: 02/Nov/09  Updated: 12/Aug/14

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

Type: Bug Priority: Major
Reporter: nick_belaevski Assignee: Unassigned
Resolution: Unresolved Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File jsf-spec.patch    
Issuezilla Id: 658
Status Whiteboard:

cat1 frame size_large importance_medium


 Description   

Contract of PartialViewContext doesn't give enough freedom for JSF components libraries to override it
partially. Example: simple addition of "extension" element (or any other that RI's implementation doesn't
do, but component libraries may need) requires full re-implementation of PartialViewContext class, thus
making co-existence of different libraries almost impossible. If some AJAX-updated component outputs
"extension" element, then it appears inside "update" element causing malformed XML error on the client,
so this approach doesn't work.



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

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

2.0 rev a

Comment by Ed Burns [ 15/Mar/10 ]

frame

Comment by rogerk [ 14/May/10 ]

Just to be clear...
Are you proposing an API change on PartialViewContext?
Can you please provide a more concrete example and use case?

Comment by rogerk [ 14/May/10 ]

Ownership

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by rogerk [ 17/May/10 ]

Target 2.1

Comment by nick_belaevski [ 18/May/10 ]

More concrete example can be update/insertion/deletion of component part. Let's
take filterable data table component. When user types something in filter field,
live update of table content should be happening, but we aren't going to update
the whole table, because this will cause loss of user's input focus. So,
component assigns id="#

{clientId}:tbody" to <tbody> element with the intention
to update it later by special event.

Looking at the API of PartialViewContext, how would component be doing this?
There's processPartial(PhaseId phaseId) that does the complete processing and in
Mojarra it is implemented via visiting components tree using either
PartialVisitContext or FullVisitContext. So, if we add component clientId into
renderIds, implementation will call component's encodeAll(...) method wrapping
it into <update id="#{clientId}

">...</update> element. If we don't add component
clientId, then control won't be passed to component at all. If we call
startUpdate()/endUpdate() for our <tbody> from encodeAll(...), then <update>
elements are nested and XML is not correct, causing update to fail (this has
been already discussed in jsr-314 mailing list). The same problem with any
insert/delete/extension element. Solution: do complete re-write of
PartialViewContext, but this affects interoperability in a poor way.

Proposed API change: two methods that will allow users to override creation of
VisitContext & VisitCallback for the particular phase.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by rogerk [ 30/Jun/10 ]

target

Comment by rogerk [ 26/Aug/10 ]

Nick - I need to push this to 2.2 unless you can supply the spec changes.

Comment by nick_belaevski [ 26/Oct/10 ]

Created an attachment (id=318)
Proposed patch

Comment by rogerk [ 16/Nov/10 ]

triage

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.





[JAVASERVERFACES_SPEC_PUBLIC-638] Ajax Back Button Support Created: 24/Sep/09  Updated: 12/Aug/14

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

Type: New Feature Priority: Major
Reporter: driscoll Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-718 Allow PhaseListener instances to rece... Closed
blocks JAVASERVERFACES_SPEC_PUBLIC-542 autocomplete attribute missing on for... Open
Issuezilla Id: 638
Status Whiteboard:

cat2 frame size_large importance_large draft


 Description   

Many modern Ajax frameworks support back button actions.

JSF should as well.

This probably means both browser history manipulation and state restoration.
Could be pretty hard to do, but really important for being seen as a real Ajax
solution.



 Comments   
Comment by driscoll [ 08/Oct/09 ]

Also, see here for a newly proposed standard by Google:

http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

unscheduled

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 18/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

On 5 May 2010, at the JAX conference, this feature was requested, but in a slightly different guise. The
requestor wanted something like

<h:backButton ...> with an optional "number of views to go back" attribute.

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by werpu12 [ 06/Mar/12 ]

Ok Ajax back button support is tricky at best. I will investigate the following days into this issue. I know html5 will provide an official api and there are hacks which enable it via hashtags on the url. (the hashtag hacks also enable bookmarking for ajax)

I personally think in step 1 we should aim for the standardized html5 way of doing things and then aim lower with the hasthags which open another can of worms.

Comment by werpu12 [ 06/Mar/12 ]

https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history

is interesting information regarding this.

Comment by werpu12 [ 07/Mar/12 ]

Ok I was able to enable back button support with some html 5 see following link
https://gist.github.com/1993051

A detailed blog will follow. The problem i see is, that there are several approaches.
a) The simplest is to go for the pure html5 way. Then you have to snapshot the page and restore it upon a proper back button event.

b) The probably easiest one is, to enable the same by adding a html5 storage simulation and back button simulation to the page (and use hashtash for the back button simulation). This should be doable, or by simply storing the page shots in a javascript map.

c) The third one would be to enable something else via hashes in the url, that would need some server side patching additionally.

I will try to prototype approach b) tomorrow.

Comment by werpu12 [ 08/Mar/12 ]

https://gist.github.com/2000091 here is the same prototype for html4 browsers.

The problem i see here with both methods is, they are purely clientside, and rely on the state history to recover the correct state.
So they

a) need some kind of notification how deep the state history is to prevent states which result in an error.

b) it is still unclear on how to deal with embedded scripts in the page and onload handlers which rely on component initialisation.

We probably have to add a callback event which the component systems can hook in to reintialize their stuff, or we simply execute all embedded scripts even with the danger of getting sideffects.

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.





[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.





[JAVASERVERFACES_SPEC_PUBLIC-634] Add an escape attribute to h:messages and h:message like in h:outputText Created: 22/Sep/09  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 634
Status Whiteboard:

cat2 renderkitdoc size_small importance_medium


 Description   

I want to output an HTML link as part of my error message, but can't because the
HTML is escaped by h:messages. I searched Google for a workaround and found
many people have the same problem. There have even been tickets created against
JSF RI and MyFaces years ago.

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=746
http://issues.apache.org/jira/browse/MYFACES-155



 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 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

rk

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by kellerapps [ 18/Apr/11 ]

I understand the use case. I'm not convinced HTML is the best way to express this sort of thing. Maybe Message should be enriched to express link & emphasis.

Comment by bleathem [ 03/Apr/12 ]

RichFaces supports this attribute with it's rich:message component (see: http://docs.jboss.org/richfaces/latest_4_X/vdldoc/rich/message.html)

Primefaces also supports this attirbute in it's message tag:
http://blog.primefaces.org/?p=1894

It seems to me it's something the community is asking for, and should be rolled into the spec.

Comment by cagatay_civici [ 03/Apr/12 ]

I agree that this should be in spec, I've seen various posts in PrimeFaces forum and stackoverflow from users who are looking for this.

Comment by rdelaplante [ 04/Apr/12 ]

This isn't just for putting links in error messages, it can also be useful for rich error messages including bold and italic of some words.

Comment by rdelaplante [ 11/Jul/14 ]

This feature is implemented in OmniFaces:

http://showcase.omnifaces.org/components/messages

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.





[JAVASERVERFACES_SPEC_PUBLIC-631] Specify target facet name when inserting into composite component Created: 18/Sep/09  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Uncategorized
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 631-cc-insertFacet-targetName.patch     Zip Archive composite-component-targets-test-2.zip     File composite-component-targets-test.war    
Issuezilla Id: 631
Status Whiteboard:

size_medium importance_medium

Tags: adf

 Description   

As discussed on jsr-314-open...

As currently specified, composite:insertFacet's "name" attribute serves two purposes:

1. It identifies the name of the facet on the containing composite component to insert.
2. It identifies the name of the facet on the target component into which the facet is being inserted.

As a result, the name of the facet exposed by the composite component must match the name of the
facet on the implementation component into which the facet is being inserted. So, for example, if I
have a composite component as follows:

<composite:interface>
<composite:facet name="caption"/>
</composite:interface>

<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
</composite:implementation>

Everything is happy, since both the composite component and the h:panelGrid expose a "caption" facet.

However, if I want to define a composite component with two h:panelGrid components and two
captions:

<composite:interface>
<composite:facet name="caption"/>
<composite:facet name="backupCaption"/>
</composite:interface>

<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>

<h:panelGrid>
<!-- Uh oh. -->
<composite:insertFacet name="backupCaption"/>
</h:panelGrid>
</composite:implementation>

I am out of luck, since I now have a mismatch between the composite component facet name and the
h:panelGrid facet name.

I think that we could/should solve this in one of two ways:

1. Add an attribute to composite:insertFacet that allows a target facet name to be specified:

<h:panelGrid>
<composite:insertFacet name="backupCaption" targetName="caption"/>
</h:panelGrid>

2. Specify that the target facet name can be picked up from a wrapping <f:facet> tag:

<h:panelGrid>
<f:facet name="caption">
<composite:insertFacet name="backupCaption"/>
</f:facet>
</h:panelGrid>



 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 Ed Burns [ 04/Mar/10 ]

Because we now have renderFacet and insertFacet, I'm wondering if this is still valid? Can you re-
open if so?

Comment by aschwart [ 30/Sep/10 ]

I find the insertFacet tag to be useless without this fix. I think that we should address this, perhaps for
2.2.

Comment by Ed Burns [ 30/Sep/10 ]

Don't know how this ended up being assigned to javaserverfowner. I thought we
re-assigned all of those.

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=322)
Patch with solution involving add "targetName" attribute

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=323)
WAR file from test project

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=324)
Test demo using maven. To run type: mvn clean -Djsf=mojarra jetty:run

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Jakob Korherr [ 31/Oct/10 ]

IMHO it should be targeted for 2.1

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-609] ui:repeat varStatus incompletely specified. Created: 12/Aug/09  Updated: 01/Aug/14

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 609
Status Whiteboard:

cat2 vdldoc size_small importance_small


 Description   

The varStatus attribute on ui:repeat supports some of the concepts present in JSTL's LoopTagStatus [1],
including the "begin" and "end" concept. However, the corresponding attributes from c:forEach are not
exposed on ui:repeat. This issue would like to fix that.

[1] http://java.sun.com/javaee/6/docs/api/javax/servlet/jsp/jstl/core/LoopTagStatus.html



 Comments   
Comment by Ed Burns [ 12/Aug/09 ]

Taking the documentatation from c:forEach [1]

begin If items specified: Iteration begins at the item located at the specified index. First item of the
collection has index 0. If items not specified: Iteration begins with index set at the value specified.

end

If items specified: Iteration ends at the item located at the specified index (inclusive). If items not
specified: Iteration ends when index reaches the value specified.

[1] http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/c/forEach.html

Comment by Ed Burns [ 12/Aug/09 ]

Target to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

vdl

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JSR-303 integration] @Valid support for custom types (JAVASERVERFACES_SPEC_PUBLIC-972)

[JAVASERVERFACES_SPEC_PUBLIC-543] @Valid and JSF Created: 17/Apr/09  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.2 Sprint 8
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: Ed Burns 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


Issuezilla Id: 543
Status Whiteboard:

cat2 frame size_medium importance_medium


 Description   

Consider this using page

<h:form>
<h:inputText value="#{person.name" />
<h:inputText value="#{person.email" />

<ez:address person="#

{person"}

>
<f:validateBean />
</ez:address>

</h:form>

and this composite component

<comp:interface>
<comp:attribute name="person" />
<comp:editableValueHolder target="street" />
<comp:editableValueHolder target="city" />
</comp:interface>

<comp:implementation>
<h:inputText value="#

{cc.attrs.person.address.street}

" />
<h:inputText value="#

{cc.attrs.person.address.city}

" />
</comp:implementation>

I'd like to be able to simply put the JSR-303 @Valid annotation on the entire Person bean and know that
the fields will be validated appropriately according to the rules for that annotation. Currently I don't
think this is possible.



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

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

sheetalv

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by gerhard_petracek [ 15/Apr/11 ]

BV v1 doesn't allow @Valid at the class level - see:
@Target(

{ METHOD, FIELD, CONSTRUCTOR, PARAMETER }

)
@Retention(RUNTIME)
public @interface Valid {}

What we should support is something similar - see http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-972

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all of Sheetal's spec issues to me.

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting to priority Major. Please check latest iteration of BeanValidator to see if this is already working.





[JAVASERVERFACES_SPEC_PUBLIC-457] Use EL in message bundles Created: 31/Aug/08  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Platform Integration (except for Bean Validator)
Affects Version/s: 2.2 Sprint 8
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: pmuir 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: All


Issuezilla Id: 457
Status Whiteboard:

EGTop5 cat2 frame size_medium importance_large draft


 Description   

Motivation
------

EL is pervasive in JSF, except in one obvious place, message bundles. Adding
this support would be natural for the developer, and in some respects increase
DRY (by not requiring parameters to specified in each place the message is used).

Proposal
------

Support the use of EL in the values of the key-value pairs present in any bundle
that is loaded via <f:loadBundle /> or via the <message-bundle> element in
faces-config.xml. The EL expression should be parsed out of the value String,
and evaluated as a value expression.



 Comments   
Comment by pmuir [ 10/Oct/08 ]

A JBoss top priority issue issue

Comment by Ed Burns [ 15/Oct/08 ]

Change target milestone to 2.0

Comment by Ed Burns [ 10/Aug/09 ]

move to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by kito75 [ 24/Feb/10 ]

Changed to platform integration (may not be the right subcomponent). Changed
milestone to 2.0 Rev A.

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

frame

Comment by Ed Burns [ 02/May/10 ]

New functionality, move to 2.1

Comment by Ed Burns [ 02/May/10 ]

New functionality, move to 2.1

Comment by Ed Burns [ 10/May/10 ]

cat2

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

Move these to M5

Comment by Ed Burns [ 30/Aug/10 ]

Move these to 2.2

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-353] Only halt component processing on disabled not readOnly Created: 08/Apr/08  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 1.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: youngm 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: All


Issuezilla Id: 353
Status Whiteboard:

EGTop5 effort_moderate cat2 size_medium importance_large draft


 Description   

Currently the renderkit docs for input specify that in decode no further
processing of a component should take place if it is readOnly or disabled.

I'd like to propose that this get modified to only apply to "disabled".
According to (http://www.w3.org/TR/html401/interact/forms.html#adef-readonly)
readonly input elements cannot be modified by the user. However, they can be
modified by a script and it IS submitted with the form.

For example. You might have a standard "datepicker" JS component. I may attach
a javascript datepicker to an inputText component. If I want only the
datePicker JS to modify the inputtext then I would set it to "readOnly". This
will restrict user modification of the field but allow Script modification.
When this form is submitted I would expect JSF to process the date entered using
the date picker JS just like it would a non "readonly" input element.

The big difference between disabled and readonly is disabled elements are not
submitted with the form.

I would expect JSF to process 'readOnly" elements but not "disabled" elements.

Mike



 Comments   
Comment by Ryan Lubke [ 08/Apr/08 ]

Updated target milestone.

Comment by rogerk [ 22/Aug/08 ]

Status Whiteboard

Comment by Ed Burns [ 12/Sep/08 ]

effort_moderate

Comment by Ed Burns [ 12/Sep/08 ]

change target_milestone to 2.0

Comment by Ed Burns [ 28/Jul/09 ]

Push to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by kito75 [ 24/Feb/10 ]

Changed subcomponent to Components/Renderers.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 27/Aug/10 ]

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

Comment by rogerk [ 16/Nov/10 ]

triage

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting to Major





[JAVASERVERFACES_SPEC_PUBLIC-345] Support for custom resource bundle loading implementation Created: 26/Mar/08  Updated: 01/Aug/14

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Configuration/Bootstrapping
Affects Version/s: 2.0
Fix Version/s: None

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

Operating System: All
Platform: All


Issuezilla Id: 345
Status Whiteboard:

EGEasy5 cat2 frame size_small importance_medium


 Description   

Java 6 supports custom resource bundle loading implementations. It would be nice
to have similar support for JSF, so that messages could be easily loaded for
example from database instead of property files in classpath.



 Comments   
Comment by rogerk [ 22/Aug/08 ]

Status Whiteboard

Comment by pmuir [ 24/Aug/08 ]

Roger, I think this got put in the wrong pile.

I don't think we need any changes here - JSF already supports loading a custom
resource bundle through faces-config.xml (you can point this at a class OR at a
path to a properties file). Thats all you need to provide a custom Java6
resource bundle.

Comment by pmuir [ 24/Aug/08 ]

Change to WORKSFORME.

Comment by syvalta [ 25/Aug/08 ]

Ok, lets have an example. I have 10 resource bundles in custom XML format. To be
able to use them, I need to provide a Java class for every one of them. Instead,
if I could define a custom resource provider, it could load the files. Hope this
clarifies this issue.

The second issue is that xml property file format is not currently supported.
Could it be supported in JSF 2.0? (is this a spec or implementation issue?)

Comment by pmuir [ 25/Aug/08 ]

To clarify, the user is looking for a way to specify the ResourceBundle.Control
object, I think from the <f:loadBundle /> tag.

I would suggest opening a second issue for your second RFE as it's a separate issue.

Comment by syvalta [ 25/Aug/08 ]

Yes, exactly, and also for <resource-bundle>(/<message-bundle>) in
faces-config.xml. Sorry for inaccuracy.

Comment by Ed Burns [ 23/Sep/08 ]

target 2.0

Comment by rdelaplante [ 27/Oct/08 ]

I have created a system for loading facelet templates from theme directories on
the filesystem (not in a .jar on classpath). The resource bundles (messages in
.properties files) live in the theme directories. I am unable to use
faces-config.xml to statically define resource bundles for themes since they are
discovered at runtime. Being able to specify a ResourceBundle.Control in
f:loadMessages may help, but I would prefer to have an addResourceBundle to the
Application object in FacesContext. Let me specify a name for EL, and provide
the ResourceBundle.Control. There might be other method signatures people find
useful, such as providing an instance of ResourceBundle instead of
ResourceBundle.Control.

Comment by rdelaplante [ 27/Oct/08 ]

Added self to CC list

Comment by syvalta [ 26/Mar/09 ]

Just for reference, the xml property file format issue is tracked at
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=452

Comment by Ed Burns [ 24/Sep/09 ]

Move to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





UIData needs review on a couple of fronts (JAVASERVERFACES_SPEC_PUBLIC-935)

[JAVASERVERFACES_SPEC_PUBLIC-322] Add interfaces to javax.faces.component package Created: 21/Nov/07  Updated: 04/Aug/14

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

Type: Sub-task Priority: Major
Reporter: mwessendorf Assignee: Unassigned
Resolution: Unresolved Votes: 8
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-236 UIData is Fundamentally Broken and Ne... Closed
Issuezilla Id: 322
Status Whiteboard:

EGTop5 effort_moderate cat2 javadoc size_medium importance_medium draft


 Description   

There are currently nice interfaces, like ValueHolder and EditableValueHolder.
But this isn't enough.

The minimal contract of creating a (custom) JSF component is UIComponent.
It is not necessary to extend something like UIComponentBase or even UIInput,
which is good.

For instance for checking if a component is able to be validated, some do a
instanceof UIInput, which would fail in some cases (as in Trinidad). Luckily
enough, we have the EditableValueHolder interfaces, so checking against that is
fine.

I noticed a lot of issues in the past with UIForm, since there is not "Form"
interface for that. One of the issues, when making Tomahawk working with
Trinidad/ADF Faces was that the Trinidad/ADF Faces form isn't extending UIForm
(which isn't wrong). We ended up, using a String-based identifier (component
family) for ensuring the component (from Trinidad) is a form. With an interface
for Form (like for EditableValueHolder) there weren't a need for "checking Strings".

This is true for "table components" as well. A "table interface" would be nice.



 Comments   
Comment by mwessendorf [ 19/Aug/08 ]

On an interface for "Form", I can think about things like:
-autoComplete
-usesUpload (bool, when TRUE => set enctype="multipart/form-data")
(and/or enctype)
-prependId
-defaultCommand (executed when hitting ENTER inside the form)

On an interfaces for Tables (call it structuredData or so, since it could be
implemented in a custom Tree, for instance) I can think of these:
-var ?
See Trinidad's UIXCollection CLASS, which is the base for all structured Data
(in Trinidad):
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/component/UIXCollection.html

Again such a "generic" interfaces could be useful when creating tree's (instead
of extending UIData (like Tomahawk or the Hans Bergsten book).

But... it is really important to have STRONG types, instead of messing around
with Strings (component family)

Comment by Ed Burns [ 21/Aug/08 ]

Add status whiteboard: EGTop5

Comment by Ed Burns [ 12/Sep/08 ]

effort_moderate

Comment by Ed Burns [ 12/Sep/08 ]

change target_milestone to 2.0

Comment by Ed Burns [ 17/Sep/08 ]

As discussed at JSFOne, I think we need a behavioral interface for components that manage collections of
children, such as trees, tables, and such.

Comment by Ed Burns [ 15/Oct/08 ]
      • Issue 189 has been marked as a duplicate of this issue. ***
Comment by kito75 [ 16/Oct/08 ]

It'd make sense to expose a isPostBack() method (which I think is on
FacesContext in 2.0) through the Form interface, as well.

Comment by Ed Burns [ 21/Oct/08 ]
      • Issue 245 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 28/Jul/09 ]

We just didn't get to this one. Sorry Matzew.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by Ed Burns [ 24/Feb/10 ]

I really don't think this is a P1 also.

Comment by kito75 [ 24/Feb/10 ]

Matthias, aren't your example form properties more renderer-specific?

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

javadoc

Comment by Ed Burns [ 22/Mar/10 ]

components

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

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.

Comment by Ed Burns [ 04/Aug/14 ]

Target for 2.3





[JAVASERVERFACES_SPEC_PUBLIC-307] Ajax Push (Reverse/Comet) Created: 18/Sep/07  Updated: 01/Aug/14

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-293 Ajax umbrella issue Closed
Issuezilla Id: 307
Status Whiteboard:

cat2 frame size_large importance_medium


 Description   

The specification must define the APIs/SPIs for pushing server side state
changes to the client (a.ka. comet, reverse ajax,...).
-------------------------------
Norbert Truchsess wrote:
> For real asynchronous comet-style communication there is an api to
> access the component-tree asynchronously on the server not in response
> to an HttpRequest (e.g. from a message-driven bean). Any change to the
> tree- and component state would be send to the client with the next
> response. In case of client-site statesaving the 'non httprequest based'
> call would be queued until the next HttpRequest comes in, then the state
> would be restored, the queued 'non-httprequests' would be processed in
> the same order they arrived and after that the regular processing of the
> HttpRequest would continue. In case of client-side statesaving where a
> communication-channel to the client is allready open (e.g. by means of a
> 'delayed' request that does not nessesarely contain the state) the
> delayed request would be released first, if it contains the state
> processing could continue as in the 'serverside statesaving' case. If no
> state is included in the request there would be an immediate response to
> the client containing a message that forces the client to send the state
> in a new request and processing may continue as described before.
-------------------------------
Roger Kitain wrote:
Sounds interesting. But how does this tie in with the inclusion of "Comet" in
the Servlet specification (JSR 315)? Does that simplify what you describe here?
-------------------------------
Norbert Truchsess wrote:
> The JSR 315 proposal talkes about non-blocking
> input/output, delayed request-handling, delayed response-close and
> Blocking/nonblocking notification (channel concept with the ability to
> subscribe to and get asynchronous events from that channel). The first 3
> items are just nessesary to do the client/server-part of the
> communication. If the last item (blocking/nonblocking notification) is
> describing a server-side feature (it sounds like the description of an
> existing feature in Grizzly), then it might/will help a lot to implement
> what I described above.
-------------------------------
Ted Goddard wrote:
> The approach taken by ICEfaces is essentially to allow the
> application to retain a reference to the FacesContext outside
> of the servlet request/response (we call it a PersistentFacesState).
> Then, the application can invoke render() on the associated
> component tree at any time, causing any page updates to be pushed
> to the client. Only one simultaneous render of the component tree
> is allowed, so client-initiated updates and server-initiated updates
> are applied coherently.
>
> We did not support client-side state saving with Ajax Push because
> a server-initiated update is only meaningful when the server has
> full knowledge of what it is updating ... but perhaps there is
> a use case where it can be applied.
-------------------------------
Norbert Truchsess wrote:
> Shure there's no gain in doing
> server-initiated updates without having access to the state on the
> serverside. But 'having' to retain the complete state on server (as it's
> done by ICEFaces results in quite limited scalability due to memory
> consumption. It would be beneficial to mark which parts of the
> component-tree-state are required during a server-initiated update so
> either only this part would be stored on the server or only this part
> would have to be 'requested' from the client before a server-initiated
> update could take place.

> My opinion here: let's target best of breed support for ajax in the
> framework itself. And that is support for 'real' comet-style push
> updates that can be used without any vendor-extensions 'out of the box'.
> We all know that the jcp is turning much slower than the techniques
> being used in the real world are evolving. At the time JSF 2.0 will be
> ready to ship the ajax-techniques being used out there world will be way
> more advanced then they are now and I bet support for
> comet-communication will be commodity in most 'non java based'
> web-application frameworks. If we don't have support for this 'build
> into the bases', jsf 2.0 will not be as attractive as it could be.
>
> Shure, not everyone needs it. Most enterprise-applications will do
> without it. So it should be optional to use - best would be to be able
> to switch in on/off at runtime for precisely that single page that e.g.
> contains a 'chat-component'. But wouldn't it be really cool, if you
> could use a chat-component by just placing it on the page and set
> 'communicationStyle="comet" in the view-tag? I'm more than convinced
> that this feature would rise the recognition of JSF as a modern
> technologie way more than most other things on our roadmap will do.
>
> This particular issue should not be priorized low just because a lack
> of resources in this EG. I hereby volunteer to write this chapter, the
> code and the tck even single-handet if no one else is willing to do
-------------------------------
Ted Goddard wrote:
> Ajax Push (also known as "comet", although that tends to
> refer to the Dojo implementation) is the main distinguishing
> feature of ICEfaces. ICEfaces is open source, so there is
> no barrier in principle to incorporating any desired
> parts of it into JSF 2.0.
>
> In terms of the technology, should it be part of JSF 2.0?
> - the server infrastructure really requires changes to the
> Servlet API (although asynchronous I/O is a goal of JSR-315)
-------------------------------
Norbert Truchsess wrote:
> I did invest quite some time to dig through ICEFaces
> implementation details, and from an architectural point of view I like
> it a lot. So if there would be no memory-contrains in reall-world
> scenarios I'd love to just take and transfer it into JSF 2.0. And in the
> reall world developers will not want to be constrained in using
> client-side widgets that do dom-manipulations on the client. (which also
> would be in conflict with our first assumtion 'Ajax.A01')
-------------------------------
Ted Goddard wrote:
> It's the JavaScript aspect that makes me hesitant to advocate
> Ajax Push for JSF 2.0 (since the Servlet changes are on the
> horizon), but I could certainly be persuaded otherwise.
-------------------------------
Roger Kitain wrote:
If would like to focus more on what's required on the server to facilitate this
feature, and ** not ** standardize lots of javascript (if that's possible).
-------------------------------
Norbert Truchsess wrote:
> 100% agree - Not
> that I think we could go without JS on the client here, but the the
> server-side requirenments are the prerequisite that has to be done first.



 Comments   
Comment by rogerk [ 18/Sep/07 ]

Set target milestone 2.0

Comment by Ed Burns [ 09/Sep/08 ]

Push to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 20/Jan/10 ]

Target 2.1

Comment by Ed Burns [ 02/Mar/10 ]

status

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 22/Mar/10 ]

ajax

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by arjan tijms [ 09/May/13 ]

Now that WebSockets have been standardized in Java EE 7 (JSR 356), it might be the right time to reconsider standardizing push for JSF.

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-205] Custom by-class converters not considered in UISelect{One,Many}.validateValue() Created: 10/Aug/06  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns 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: GZip Archive jsf-api-205.tar.gz     Text File message.txt     File prova2.war     Zip Archive src.zip    
Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-57 Converters - Tied into PropertyResolv... Closed
Issuezilla Id: 205
Status Whiteboard:

cat2 frame javadoc size_small importance_large


 Description   

al80 on ##jsf on freenode found this one, and it appears to be a good candidate
for the upcoming MR.

Look at the javadocs for UISelect

{One,Many}

.validateValue():

  • Before comparing each option, coerce the
  • option value type to the type of this component's value following
  • the Expression Language coercion rules.

If you have a custom converter installed as a by-type converter, then it will
have been used to convert the value before calling into validateValue().
However, when the EL coercion rules are used, this by-type converter is not
consulted.



 Comments   
Comment by Ed Burns [ 10/Aug/06 ]

Created an attachment (id=101)
al80's test war

Comment by Ed Burns [ 10/Aug/06 ]

Created an attachment (id=102)
java sources for war

Comment by Ed Burns [ 10/Aug/06 ]

Add jan to CC.

Comment by Ed Burns [ 10/Aug/06 ]

EL Spec section 1.18.7 has this to say about custom coercion.

Coerce
AtoAnyOtherTypeT
â–  IfAisnull, returnnull
â–  IfAisassignabletoT, coercequietly
â–  IfAisaString, andThasnoPropertyEditor:
â–  IfAis"", returnnull
â–  Otherwiseerror
â–  IfAisaStringandT'sPropertyEditorthrowsanexception:
â–  IfAis"", returnnull
â–  Otherwise, error
â–  Otherwise, applyT'sPropertyEditor
â–  Otherwise, error

Comment by Ed Burns [ 10/Aug/06 ]

Created an attachment (id=103)
fix for this bug, first iteration

Comment by Ed Burns [ 10/Aug/06 ]

Created an attachment (id=104)
tarball of modified and new files for first iteration bugfix.

Comment by Ed Burns [ 10/Aug/06 ]

Attachment 103 is a JSF Impl based fix for this issue, but I do think something
should be done at the spec level. There is no sense in requiring someone to
write a converter twice: once as a JSF Converter and once as a PropertyEditor.

Comment by Ed Burns [ 11/Aug/06 ]

After thinking about this some more, I have to wonder, why don't we just use
UIInput.getConvertedValue() rather than the EL's coerceToType() in the
UISelect

{One,Many}

.matchValue() implementation?

Comment by Ed Burns [ 16/Aug/06 ]

take ownership

Comment by Ed Burns [ 24/Aug/06 ]

Let's defer this to 2.0. At least we have a by-type solution in the Sun Impl.

Comment by Ryan Lubke [ 20/Aug/08 ]

57 is an umbrella issue for this one.

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

javadoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

Move these to M5

Comment by Ed Burns [ 30/Aug/10 ]

Move these to 2.2

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Set priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-201] Locale handling in f:convertDateTime and f:convertNumber Created: 06/Aug/06  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.2 Sprint 8
Fix Version/s: None

Type: Bug Priority: Major
Reporter: tony_robertson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 201
Status Whiteboard:

EGEasy5 cat2 frame size_small importance_medium


 Description   

The handling of the "locale" attribute in the JSF core taglib tags
<f:convertDateTime> and <f:convertNumber> is inconsistent with each other and
with the handling of the "locale" attribute in the <f:view> view-root tag.

For <f:convertDateTime>, the description mandates that the implementation must
pass any string value as the first arg to the two-arg Locale constructor, and
pass the empty string as the second arg.

For <f:convertNumber>, the tld docs imply that string values are not supported
at all, but the sun javaserverfaces api implementation does allow literal
strings that are treated the same way as for <f:convertDateTime>.

In both cases, it would be more useful and consistent if String values were
treated as references to locale "names" using the same syntax as for the
<f:view> locale attribute (ie, allow language-country-variant type strings).

Placing support for a standard "locale" attribute in the <f:converter> tag may
be a good way to provide consistent behaviour for both <f:convertDateTime>,
<f:convertNumber>, and any user supplied custom converters.



 Comments   
Comment by rogerk [ 22/Aug/08 ]

Status Whiteboard

Comment by Ed Burns [ 02/Sep/08 ]

take ownership

Comment by Ed Burns [ 23/Sep/08 ]

target 2.0

Comment by Ed Burns [ 28/Jul/09 ]

We didn't get to this one. Sorry.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major because it involves multiple tags





[JAVASERVERFACES_SPEC_PUBLIC-1285] f:selectItems ignore itemDescription within h:selectOneListbox and related components Created: 19/Jun/14  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Facelets tag lib documentation shows the following properties as valid for f:selectItems:

itemValue
itemLabel
itemDescription
itemDisabled
itemLabelEscaped
...

But in both Mojarra and MyFaces the attribute itemDescription, itemDisabled, itemLabel are ignored.

But taking a look at the renderkit spec javadoc of javax.faces.SelectMany/javax.faces.Listbox in the section "Rendering the "option" elements" it says this:

"... If the current child is a UISelectItem create a SelectIteminstance from its itemValue, itemLabel, itemEscaped, and itemDescription properties, add it to the list. If the current child is a UISelectItems instance, call its getValue() method. If the result is a SelectItem bean, add it to the list. If the result is an array of SelectItem beans, add each one to the list. If the result is a Collection of SelectItem beans, add each one to the list. If the result is a Map, create a SelectItem bean for each entry in the Map using the key as the label, the value as the value, and null as the description. ..."

So, these properties are supposed to be used with f:selectItem, not with f:selectItems. But the user perceive this as a bug, which is something logic. See:

https://issues.apache.org/jira/browse/MYFACES-3901

In JSF 2.2 with HTML5 friendly markup, it is supposed that f:selectItems can have passthrough attributes. See:

https://issues.apache.org/jira/browse/MYFACES-3879

But in MyFaces we found that it doesn't work for h:selectOneRadio or h:selectManyCheckbox.

The thing is the fix for this issue is pretty similar for the one that needs to be done for HTML5 friendly markup.



 Comments   
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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1296] Clarify when it is valid to instantiate and use a PartialResponseWriter Created: 30/Jul/14  Updated: 13/Aug/14

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3358 Allow for creation of PartialViewCont... Closed

 Description   

The spec makes an implicit assumption about when it is valid to instantiate a PartialViewContext(). This assumption is: the current execution context must have FacesServlet.service() above on the callstack, which implies the existence of a FacesContext.



 Comments   
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.





[JAVASERVERFACES_SPEC_PUBLIC-1295] Add default implementation for UIComponent#getFamily() Created: 20/Jul/14  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

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

Tags: ease-of-use, ease_of_development

 Description   

Custom components inheriting from UIComponentBase are currently required to provide an implementation for UIComponent#getFamily() as it's an abstract method.

This is a small nuisance for simple custom components (e.g. ones used internally by some application), which rarely have any need for distinguishing components based on family.

Typically those components just return the empty string or null (JAVASERVERFACES_SPEC_PUBLIC-1267) or some nonsense string like "whatshouldido.with.this".

If developers are not providing any meaningful return value for this method, I guess JSF might just as well provide a default implementation in UIComponentBase (e.g. a method just returning null), thereby making custom components yet again a tiny bit easier to create.



 Comments   
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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1291] RFE: Ability for h:messages to display a single custom message whenever the component has received any faces message. Created: 11/Jul/14  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

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

Attachments: PNG File single message.png    

 Description   

In OmniFaces you can use h:messages to display a single message at the top of the screen such as "There are validation errors. Please fix them.", and then display component specific messages beside the components. They have added a "for" attribute to h:messages that points to the form component, and a "message" for the message to display. I will attach a screenshot.

http://showcase.omnifaces.org/components/messages

I've had customers ask me to do this very thing in our production applications.



 Comments   
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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1290] RFE: Add a var attribute to h:messages that enables the developer to fully control output styling Created: 11/Jul/14  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

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


 Description   

Please see the OmniFaces messages component:

http://showcase.omnifaces.org/components/messages

"Control iteration markup fully by the new var attribute which sets the current FacesMessage in the request scope and disables the default table/list rendering."

<o:messages var="message">
<li class="#

{fn:toLowerCase(message.severity)}

">#

{message.summary}

</li>
</o:messages>



 Comments   
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.





[JAVASERVERFACES_SPEC_PUBLIC-1289] RFE: When the required attribute of a checkbox is set to true, a validation error should occur when the form is submitted and the checkbox is not checked Created: 11/Jul/14  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

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