[JAVASERVERFACES_SPEC_PUBLIC-1399] Allow for UTF-8 in links Created: 19/Aug/15  Updated: 19/Aug/15

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

Type: Improvement Priority: Critical
Reporter: Manfred Riem Assignee: balusc
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-4005 Cutting symbols while URL-Encoding by... Open




[JAVASERVERFACES_SPEC_PUBLIC-1393] Let CDI handle #{requestScope} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1388] Let CDI handle #{headerValues} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1391] Let CDI handle #{paramValues} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1394] Let CDI handle #{resource} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1389] Let CDI handle #{initParam} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1392] Let CDI handle #{request} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1387] Let CDI handle #{header} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1390] Let CDI handle #{param} Created: 30/Jul/15  Updated: 20/Aug/15

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

Type: Improvement 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:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open




[JAVASERVERFACES_SPEC_PUBLIC-1386] Let CDI handle #{flowScope} Created: 30/Jul/15  Updated: 21/Aug/15

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

Type: Improvement 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

Attachments: Text File changebundle-tmp-workaround.txt     Text File changebundle.txt     Zip Archive newfiles.zip    
Issue Links:
Blocks
blocks JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open

 Comments   
Comment by Manfred Riem [ 21/Aug/15 ]

If you can fix Javadoc copy-paste error ("SessionMap") then r=mriem

Comment by arjan tijms [ 21/Aug/15 ]

copy/paste error fixed and committed to 2.3 trunk:

svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1386, CDI producer for #

{flowScope}

, r=mriem"
Adding jsf-api/src/main/java/javax/faces/annotation/FlowMap.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/CdiExtension.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/FlowMapAnnotationLiteral.java
Adding jsf-ri/src/main/java/com/sun/faces/cdi/FlowMapProducer.java
Sending jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java
Adding test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectFlowMapBean.java
Adding test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectFlowMapBeanX.java
Sending test/javaee8/cdi/src/main/webapp/WEB-INF/web.xml
Adding test/javaee8/cdi/src/main/webapp/flow
Adding test/javaee8/cdi/src/main/webapp/flow/flow-flow.xml
Adding test/javaee8/cdi/src/main/webapp/flow/flow.xhtml
Adding test/javaee8/cdi/src/main/webapp/flow/next.xhtml
Adding test/javaee8/cdi/src/main/webapp/flowx
Adding test/javaee8/cdi/src/main/webapp/flowx/flowx-flow.xml
Adding test/javaee8/cdi/src/main/webapp/flowx/flowx.xhtml
Adding test/javaee8/cdi/src/main/webapp/flowx/next.xhtml
Adding test/javaee8/cdi/src/main/webapp/injectFlowMap.xhtml
Adding test/javaee8/cdi/src/test/java/com/sun/faces/test/javaee8/cdi/Spec1386IT.java
Sending test/javaee8/el/src/main/webapp/WEB-INF/web.xml
Adding test/javaee8/el/src/main/webapp/flow
Adding test/javaee8/el/src/main/webapp/flow/flow-flow.xml
Adding test/javaee8/el/src/main/webapp/flow/flow.xhtml
Adding test/javaee8/el/src/main/webapp/flow/next.xhtml
Adding test/javaee8/el/src/main/webapp/flowMap.xhtml
Adding test/javaee8/el/src/main/webapp/flowx
Adding test/javaee8/el/src/main/webapp/flowx/flowx-flow.xml
Adding test/javaee8/el/src/main/webapp/flowx/flowx.xhtml
Adding test/javaee8/el/src/main/webapp/flowx/next.xhtml
Adding test/javaee8/el/src/test/java/com/sun/faces/test/javaee8/el/Spec1386IT.java
Transmitting file data .........................
Committed revision 15033.

Comment by arjan tijms [ 21/Aug/15 ]

Tmp change of EL name to avoid since clash, since even producers are not totally deactivated and still present now.

Applied to 2.3 trunk:

svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1386, Temp EL name change to fix tests, r=mriem"
Sending jsf-ri/src/main/java/com/sun/faces/cdi/FlowMapProducer.java
Sending test/javaee8/el/src/main/webapp/flow/flow.xhtml
Sending test/javaee8/el/src/main/webapp/flow/next.xhtml
Sending test/javaee8/el/src/main/webapp/flowx/flowx.xhtml
Sending test/javaee8/el/src/main/webapp/flowx/next.xhtml
Transmitting file data .....
Committed revision 15036.





[JAVASERVERFACES_SPEC_PUBLIC-1329] @NotNull for f:viewParam is not triggered when the parameter is missing in the query string Created: 21/Oct/14  Updated: 28/Aug/15

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

Type: Improvement Priority: Major
Reporter: balusc Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 25 minutes
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by JAVASERVERFACES-3339 @NotNull for f:viewParam is not trigg... Closed

 Description   

@NotNull bean validation isn't being considered for <f:viewParam> whereas its own required="true" and a nested <f:validateRequired> (as per issue 3058) are correctly being considered.

I'd expect the @NotNull also being considered the same way.



 Comments   
Comment by Ed Burns [ 26/Aug/15 ]

Not enough information in the bug report to take action.

Comment by Ed Burns [ 27/Aug/15 ]

Some automated tests are failing. Revert to see if they clear out. The failures don't seem related, though.





[JAVASERVERFACES_SPEC_PUBLIC-907] Improve Ajax Http.Get support to (re)render parts of the page Created: 04/Nov/10  Updated: 01/Aug/14

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

Type: Improvement Priority: Critical
Reporter: mwessendorf 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


Issuezilla Id: 907
Status Whiteboard:

size_medium importance_large


 Description   

The current JavaScript Ajax API should be improved to have a simplified version
that allows to "just" render (several) components, via GET.

A use case would be:
-You have a client side callback that get's invoked (e.g. when a
Bayeux/WebSocket notification arrives). Inside the callback you are simply only
interested in (re)rendering some components.

Today it would look like:

webSocket.onmessage = function(evt)
{
// work with evt.data.....
jsf.ajax.request('jsfForm:dummyBtn',null,

{render:'listComp'}

);
};



 Comments   
Comment by mwessendorf [ 04/Nov/10 ]

Perhaps we could have something like:

/**

  • Issues an Http.GET request to render a set of components.
  • @param varargs that specify a list of components to re-render
    */
    jsf.ajax.renderRequest(varargs);
Comment by werpu [ 04/Nov/10 ]

I think this falls into a similar category like the ajaxed fileuploads, you have
to have a mechanism which allows a switchable transport layer.

We have the basics in myfaces already implemented, due to prototyping the ajax
fileupload for jsf 2.2, but a GET is missing on our side as well, but can be
easily added without too much effort.

Comment by mwessendorf [ 04/Nov/10 ]

For cases like this, another limitation is not only the POST. Also the fact that
'source' is needed..

jsf.ajax.request(source,null,

{render.... }

);

the event can be NULL, but source (currently) not.

Therefore we may need a new function, e.g. renderRequest() - as said before

Comment by rogerk [ 04/Nov/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 Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-904] Composite component file extensions Created: 29/Oct/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: Bug Priority: Critical
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 904
Status Whiteboard:

size_small importance_medium


 Description   

From jsr-314-open:

> Both MyFaces and Mojarra currently assume/require the file extension ".xhtml" for composite
> component resources. This seems overly restrictive. Composite component authors should be able
> to use other file extensions - eg. ".view.xml", or, as we would like to do here: ".jsf".

Thread starts here:

http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-October/000644.html



 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.





Relative Resources (JAVASERVERFACES_SPEC_PUBLIC-947)

[JAVASERVERFACES_SPEC_PUBLIC-884] Support library prefix in resource URLs Created: 17/Sep/10  Updated: 12/Aug/14

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: 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:
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-874] Clarify Executing Element Id In Ajax Request Created: 05/Aug/10  Updated: 08/Sep/14

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

Type: Bug Priority: Critical
Reporter: rogerk 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: Macintosh


Issuezilla Id: 874
Status Whiteboard:

size_small importance_medium


 Description   

On 8/3/10 10:45 AM, Werner Punz wrote:
> Hello while doing another round of testing and optimisations I noticed a
slight difference in the implementations of the request of mojarra and myfaces
which opened an area where the spec probably is unclear:
>
> Following case:
>
> <h:panelGroup id="bla">
>
> <h:inputText id="inputbla" value="#

{myBean2.searchTerm}

" />
>
> <h:commandLink value="Press me for more action"
action="#

{myBean2.doSearch}

">
> <f:ajax execute="bla" render="content"/>
> </h:commandLink>
> </h:panelGroup>
>
> now results in following post data:
>
> Mojarra:
>
> form2 form2
> form2:inputbla
> javax.faces.ViewState 6697453697014869722:-1090088301633916042
> javax.faces.behavior.even... action
> javax.faces.partial.ajax true
> javax.faces.partial.event click
> javax.faces.partial.execu... form2:j_idt8 form2:bla
> javax.faces.partial.rende... form2:content
> javax.faces.source form2:j_idt8
>
>
> in myfaces
> form2:inputbla
> form2_SUBMIT 1
> javax.faces.ViewState
EmWJgKYkJoTEWDCzpUwZQR3Ek94rGnxK1V6NEZgO6yDgPANeOc1wplJjDYezu2cx9aQ7ZSKNPyGY
L8P9y5DwH2codFvGPjklD04wuxG4XXTPutNww3pdzIsMkw0=
> javax.faces.behavior.even... action
> javax.faces.partial.ajax true
> javax.faces.partial.event click
> javax.faces.partial.execu... form2:bla
> javax.faces.partial.rende... form2:content
> javax.faces.source form2:j_id1980473354_760ba132
>
>
>
> While most of the differeing data is mostly implementation specific and
therefor it is not that interesting following is:
> javax.faces.partial.execu... form2:j_idt8 form2:bla
>
> compared to
>
> javax.faces.partial.execu... form2:bla
>
> Now the difference is that Mojarra adds the executing element as it seems
> while MyFaces does not.
> The second interesting fact is following definition from the spec:
>
> * Determine additional arguments (if any) from the options argument. If
options.execute exists:
> o If the keyword @none is present, do not create and send the post
data argument javax.faces.partial.execute.
> o If the keyword @all is present, create the post data argument with
the name javax.faces.partial.execute and the value @all.
> o Otherwise, there are specific identifiers that need to be sent.
Create the post data argument with the name javax.faces.partial.execute and the
value as a space delimited string of client identifiers.
> * If options.execute does not exist, create the post data argument with
the name javax.faces.partial.execute and the value as the identifier of the
element that caused this request.
>
>
> Which means exactly, that I am not sure which behavior is correct and which
not. My personal guess is that both implementations are
> correct because the spec clearly leaves it open if the issuing element also
can be added to the exec list unless no exec list is given at all.
> But that is merely an assumption on my side here.
> Any ideas on this.
>
> Werner

On 8/4/10 3:31 AM, Martin Marinschek wrote:
> Hi Werner,
>
> I think some clarification would certainly be good there (especially
> as the language doesn't really say what client identifiers should be
> present, plus once talks about client identifiers, and once about
> identifiers only). My POV: for now, Mojarra and MyFaces should behave
> the same. The sentence following the one that you highlighted in bold:
>
> "...with the name javax.faces.partial.execute and the value as the
> identifier of the element that caused this request..."
>
> indicates to me that the triggering client id should be there.
>
> best regards,
>
> Martin

On 8/4/10 5:08 AM, Werner Punz wrote:
> Hi,
> I just did some further digging around in the code specially since I am
currently doing some optimisation stuff in that area in myfaces. And I came to
the conclusion that Mojarras behavior breaks the spec.
>
> The reason. The spec itself leaves it open, but we have an implicit @this
parameter which can be set both in execute and in render
> and if this @this parameter is set then the issuing client id has to be set in
the list where it is set.
> So the spec clearly states here that @this is a placeholder for the executing
element. If is allowed in exec, appending automatically the issuing client id is
pointless.
>
> Werner



 Comments   
Comment by rogerk [ 05/Aug/10 ]

Evaluate

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 werpu12 [ 06/Mar/12 ]

Ok MyFaces has in the meanwhile cloned mojarras behavior in this regard. So we probably can nail down the mojarra status quo into the spec.

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-1029] viewParam value lost after validation errors Created: 02/Aug/11  Updated: 01/Aug/14

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: Unassigned
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-1028] Clarify partial state save/restore traversal requirements Created: 02/Aug/11  Updated: 12/Aug/14

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

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

Status Whiteboard:

size_small importance_medium


 Description   

Mojarra and MyFaces differ in how they implement the partial state save/restore traversals. Mojarra uses tree visiting. MyFaces does not. The spec should define requirements for this area to ensure consistency across implementations.



 Comments   
Comment by aschwart [ 02/Aug/11 ]

Expert group discussion can be found here:

http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2011-08/message/0

At this point it looks like we should specify that tree visiting should be used for these traversals, as this allows components (eg. Trinidad's UIXCollection) to intercept the traversal in order to perform component-specific processing.

Comment by Ed Burns [ 10/Aug/11 ]

Added to JSF_2_2_WORKING_SET <http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10531>. Added estimates.

Comment by Ed Burns [ 22/Dec/11 ]

Deprecate StateManager, point to StateManagementStrategy. In StateManagementStrategy, require the use of the visit API to perform the saving. http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1028

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/application/Application.java

  • mark {get,set}

    StateManager() as deprecated, pointing to the new
    equivalents.

M jsf-api/src/main/java/javax/faces/application/StateManager.java
M jsf-api/src/main/java/javax/faces/application/StateManagerWrapper.java

  • Deprecate these classes, pointing to the new equivalents.

M jsf-api/src/main/java/javax/faces/view/StateManagementStrategy.java

  • require the use of the visit API to perform the saving.

M jsf-api/src/main/java/javax/faces/context/FacesContext.java

  • fix javadoc error

Committed to trunk:

Sending jsf-api/src/main/java/javax/faces/application/Application.java
Sending jsf-api/src/main/java/javax/faces/application/StateManager.java
Sending jsf-api/src/main/java/javax/faces/application/StateManagerWrapper.java
Sending jsf-api/src/main/java/javax/faces/context/FacesContext.java
Sending jsf-api/src/main/java/javax/faces/view/StateManagementStrategy.java
Transmitting file data .....
Committed revision 9542.

Comment by Ed Burns [ 22/Dec/11 ]

Need to re-open to consider Ted Goddard's additional requests on this issue.

Comment by Ed Burns [ 22/Dec/11 ]

Roll back deprecation of entire StateManager in favor of just deprecating two methods:

{save,restore}

View(). http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1028

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/application/Application.java

  • Roll back deprecation of the stateManager property.

M jsf-api/src/main/java/javax/faces/application/StateManager.java

  • Roll back deprecation of the entire class.
  • Deprecated {restore,save}

    View().

M jsf-api/src/main/java/javax/faces/application/StateManagerWrapper.java

  • Roll back deprecation of the entire class.

M jsf-api/src/main/java/javax/faces/context/PartialResponseWriter.java

  • In the value for VIEW_STATE_MARKER, rather than duplicating the
    literal string, refer to the symbolic constant
    ResponseStateManager.VIEW_STATE_PARAM, the value of which is
    equivalent to the literal string being replaced.

Committed to trunk:

Sending jsf-api/src/main/java/javax/faces/application/Application.java
Sending jsf-api/src/main/java/javax/faces/application/StateManager.java
Sending jsf-api/src/main/java/javax/faces/application/StateManagerWrapper.java
Sending jsf-api/src/main/java/javax/faces/context/PartialResponseWriter.java
Transmitting file data ....
Committed revision 9543.

Comment by Ed Burns [ 03/Feb/12 ]

Move to sprint 11

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-1126] XSD for composite components incomplete Created: 27/Jul/12  Updated: 08/Sep/14

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

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


 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-1113] onselect attribute is only supported on INPUT and TEXTAREA elements, not on SELECT elements Created: 06/Jun/12  Updated: 10/Aug/15

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

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


 Description   

As per http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents the "select" event is only supported on INPUT and TEXTAREA elements. The "onselect" attribute in h:selectOneMenu/h:selectManyMenu/h:selectOneListbox/h:selectManyListbox is therefore invalid and misleading and should be removed.



 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-1007] Explicit support for dynamic component tree manipulation Created: 22/May/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: Critical
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: components

 Description   

In JSF it's possible to manipulate a component tree using Java code after it has been build by the ViewHandler. From the very first JSF version on, there have been explicit APIs to do this manipulation.

E.g.

UIViewRoot root = FacesContext.getCurrentInstance().getViewRoot();
UIOutput output = new UIOutput();
output.setValue("Dynamically added component");
root.getChildren().add(output);

However, the exact moment when this kind of manipulation is legal to do has not been specified. In the past, people have been using various moments in the life-cycle, where success ranged from an exception, the component appearing in the rendered response but not surviving a postback, to everything working as expected. Furthermore, behavior varied between MyFaces and Mojarra.

In JSF 2.0, the PreRenderViewEvent seems like an excellent opportunity for this manipulation, but it has not been specified that this is the right moment and in practice implementations might still not support full manipulation here. See http://java.net/jira/browse/JAVASERVERFACES-1826

Proposal: Explicitly provide support for dynamic component tree manipulation, possibly by proving a special system event for this and mandating conforming implementations to fully allow such manipulations. In case this is not technically feasible, specify what kind of manipulations are guaranteed to work.



 Comments   
Comment by kennardconsulting [ 22/May/11 ]

Hi guys,

Thanks for opening this spec issue!

I'd like to point out that MyFaces, as of 2.0.3, has successfully supported dynamic component tree manipulation in all my SystemEvent Acid Tests (see https://issues.apache.org/jira/browse/MYFACES-2935) and in Metawidget (http://metawidget.org) which exercises dynamic component tree manipulation more than most.

So this spec change may be as simple as 'blessing' the MyFaces behaviour. Certainly this would seem preferrable to introducing a new SystemEvent. My only concerns:

1. The name of PreRenderViewEvent is fine, but the way you have to use it seems odd:

root.subscribeToViewEvent( PreRenderViewEvent.class, this );

I believe Ryan Lubke came up with this approach (see http://kennardconsulting.blogspot.com/2010/10/safely-manipulating-component-tree-with.html). It works, but it seems strange a component has to register against the 'UIViewRoot.subscribeToEvent' as opposed to just calling 'this.subscribeToViewEvent'? Perhaps this could be explained and documented in the spec.

2. Rinner23 has expressed concerns whether PreRenderViewEvent works inside a UIRepeat (see http://java.net/jira/browse/JAVASERVERFACES-1826?focusedCommentId=308718&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_308718). I have never tested this use case myself.

Regards,

Richard.

Comment by Ed Burns [ 06/Jun/11 ]

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

Comment by arjan tijms [ 16/Jul/11 ]

rogerk hinted at a possible necessity for this behavior to be spec'd:

I know there was some initial discussion on the EG related to this area - perhaps some of this should be spec'd so implementations have a blueprint to follow and MyFaces/Mojarra will be doing it the same way.

See: http://java.net/jira/browse/JAVASERVERFACES-1826?focusedCommentId=316876&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_316876

Comment by kennardconsulting [ 07/Nov/11 ]

I have done some further experiments using PreRenderViewEvent within 'repeater' components (such as ui:repeat and h:column).

There appears to be a fundamental problem whereby components that use PreRenderViewEvent cannot also access 'bound attribute values' (such as <h:dataTable var="internal">). Ed believes this is defined at the spec level, so needs to be fixed there too.

See http://java.net/jira/browse/JAVASERVERFACES-2089

Note there is a workaround if the parent component is defined by the developer. But this workaround is not available when using the built-in components (such as h:column).

See https://issues.apache.org/jira/browse/MYFACES-3168

Comment by Manfred Riem [ 16/May/12 ]

All the changes included in 1826, 2371, 2372 and 2373 should account for the ability to manipulate the component tree. Note that dynamic component tree manipulation can happen at any time after restoring the view and before state saving.

Comment by kennardconsulting [ 16/May/12 ]

I must point out that "the changes included in 1826, 2371, 2372 and 2373" do not fully "account for the ability to manipulate the component tree". Several show stopper bugs remain, as reported here http://java.net/jira/browse/JAVASERVERFACES-2283

Please address this! I have been waiting 2.5 years

Comment by arjan tijms [ 17/May/12 ]

Please also note the difference between the practical ability of Mojarra to allow dynamic manipulation and the spec actually demanding that compliant implementations should support this.

Comment by Manfred Riem [ 17/May/12 ]

OK I guess I need to clarify what I meant with my previous comment about 1826, 2371, 2372 and 2373. As this is a spec issue what I meant with it was the fact we have now identified at what point in the lifecycle it is save to do dynamic component tree manipulation. The following clarification / explanation can be added somewhere in the JavaDoc and/or specification. So any JSF implementation is aware of what is expected with regards to dynamic component tree manipulation.

"Dynamic component tree manipulation can happen at any time during and after restoring the view and before state saving and needs to function properly with respect to rendering and state saving"

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-947] Relative Resources Created: 09/Mar/11  Updated: 01/Aug/14

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: Unassigned
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  
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-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-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-1230] VDLDoc for <ui:repeat> does not have concept of rowStatePreserved which <h:dataTable> does have. Created: 14/Oct/13  Updated: 05/Sep/14

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: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1263 Add rowStatePreserved property to com... Open
is related to JAVASERVERFACES-2243 h:form inside nested ui:repeat fails ... Closed

 Description   

JSF 2.1 added to UIData the ability to declare that row state should be preserved on iterations. This capability should also be added to <ui:repeat>



 Comments   
Comment by Ed Burns [ 06/Mar/14 ]

>>>>> On Fri, 14 Feb 2014 16:17:46 -0500, Leonardo Uribe said:

LU> There is still a problem related to the component row state and its
LU> relation with the model. In few words, if you remove a row, since the
LU> state is associated to the rowIndex, the state of the removed row is
LU> passed to the next row and so on, breaking the state. Long time
LU> ago, I did a solution to the problem in tomahawk adding some
LU> attributes (rowKey and derivedRowKeyPrefix).

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-1217] EnumConverter.getAsString() javadoc contains incorrect text, conflicts with its own @returns clause Created: 15/Aug/13  Updated: 12/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

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

Issue Links:
Related
is related to JAVASERVERFACES-2919 selectOneMenu + EnumConverter and nul... Closed

 Description   

The Javadoc for EnumConverter.getAsString() contains the text,

If the value argument is null, return null.

This is conflict with the @returns clause, and also with the super-interface declaration of the 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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1179] Clarify UIComponent.encodeAll requirements Created: 04/Apr/13  Updated: 17/Aug/15

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

Type: Improvement Priority: Critical
Reporter: aschwart Assignee: aschwart
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As requested by Manfred here:

http://java.net/jira/browse/JAVASERVERFACES-2743

I am logging this issue to request that the spec be more explicitly in stating that JSF implementations must call UIComponent.encodeAll() instead of directly calling each of encodeBegin/encodeChildren/encodeEnd() when rendering any component.

The reason for this is that UIComponent.encodeAll() is a non-final public method that components are free to override. JSF implementations should never bypass these overrides since this can result in bugs/loss of functionality.



 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-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: 3
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-1199] Missing throws clauses in javadoc for implementing classes. Created: 11/Jun/13  Updated: 01/Aug/14

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: dougd Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A


Attachments: Text File file_list.txt    

 Description   

It appears that when we leave the javadoc of an Implementing classes method(s), that we are not getting all the throws clauses that we should be.

Example:
javax.faces.validator.MethodExpressionValidator implements the javax.faces.components.Stateholder interface, and implements saveState & restoreState methods. The API documents for these methods are copied automatically fro the StateHolder interface javadocs, but the "throws" clause is not being copied. We might need to implicitly tell the javadoc too do do this by adding something like the below.

/**

  • {@inheritDoc}
    * @throws{@inheritDoc}

    */

I have attached a file that contains a list of classes that have the "Description copied from" string in there Javadoc at some point. This file should help whom ever needs to go through and clean up the classes.



 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-807] Need to pass FacesContext instance to system event listeners Created: 24/May/10  Updated: 03/Sep/14

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

Type: Bug Priority: Critical
Reporter: lu4242 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


Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-473 FacesEvent should have a convenience ... Resolved
Issuezilla Id: 807
Status Whiteboard:

size_small importance_medium


 Description   

Reviewing some stuff, it was notice that the FacesContext instance is not passed
when event processing occur, so every time a system event should be processed, a
call to FacesContext.getCurrentInstance() should be done in almost all cases.

Below there are one example based on myfaces code (removed non relevant code):

public class HtmlStylesheetRenderer extends Renderer implements
ComponentSystemEventListener
{

public void processEvent(ComponentSystemEvent event)

{ UIComponent component = event.getComponent(); FacesContext facesContext = FacesContext.getCurrentInstance(); facesContext.getViewRoot().addComponentResource(facesContext, component, "head"); }

......
}

It could be good to pass the current facesContext (note the code in
Application.publishEvent receive it as param), to prevent those unnecessary
calls and enhance code performance. In theory it is possible to cache
facesContext object on listeners suscribed using
UIViewRoot.subscribeToViewEvent() because those listeners are not saved (but
maybe not because if the same view is used on portlet....), but that's not
possible on ComponentSystemEventListener instances.



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

Move to 2.1

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 Hanspeter Duennenberger [ 19/Nov/10 ]

If FacesContext would be passed on all FacesEvent/SystemEvent objects, every
listener would have access to the current FacesContext from FacesEvent.

Thus the below code would look like:

public void processEvent(ComponentSystemEvent event)

{ UIComponent component = event.getComponent(); FacesContext facesContext = event.getFacesContext(); facesContext.getViewRoot().addComponentResource(facesContext, component, "head"); }
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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-803] Documentation of VisitHint.EXECUTE_LIFECYCLE is not clear Created: 18/May/10  Updated: 01/Aug/14

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

Type: Bug Priority: Critical
Reporter: lu4242 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: 803
Status Whiteboard:

size_small importance_small


 Description   

Looking the documentation there is a hint called VisitHint.EXECUTE_LIFECYCLE
that says the following:

"Hint that indicates that the visit is being performed as part of lifecycle
phase execution and as such phase-specific actions (initialization) may be taken."

I understand why VisitHint.SKIP_TRANSIENT and VisitHint.SKIP_UNRENDERED, but
looking the javadoc I couldn't find when, how or why that hint should be set. At
this time, myfaces just ignore it, but if it is used, there should be some
documentation on UIComponent.visitTree or UIData.visitTree. Maybe I'm wrong
about that, and if myfaces don't use it really there is not problem, but the
point is: Is mojarra really implementing the algorithm that says the javadoc?.
It could be good if someone could check this algorithm against javadoc, because
really it is very suspicious.

ANDY>Martin suggested "EXECUTE_LIFECYCLE" for this concept, and we rolled with that.

ANDY>In the version of Mojarra that I happen to have sitting here (about a month
old), UIData is looking for this hint. However... the PartialViewContext
implementation is not actually setting the hint, so this is not actually being
used at the moment.

After discuss this stuff, it was clear the utility behind
VisitHint.EXECUTE_LIFECYCLE, but if it is used, the documentation of
UIData.visitTree should be more explicit about how and when it is used (Right
now it is not clear from where this hint should be checked and the effect)



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

move to p2

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 24/May/10 ]

Mojarra UIData has this method

private void preVisitChildren(VisitContext visitContext) {

// If EXECUTE_LIFECYCLE hint is set, we need to do
// lifecycle-related initialization before visiting children
if (visitContext.getHints().contains(VisitHint.EXECUTE_LIFECYCLE))

{ FacesContext facesContext = visitContext.getFacesContext(); PhaseId phaseId = facesContext.getCurrentPhaseId(); if (phaseId == PhaseId.APPLY_REQUEST_VALUES) preDecode(facesContext); else if (phaseId == PhaseId.PROCESS_VALIDATIONS) preValidate(facesContext); else if (phaseId == PhaseId.UPDATE_MODEL_VALUES) preUpdate(facesContext); else if (phaseId == PhaseId.RENDER_RESPONSE) preEncode(facesContext); }

}

I will update the docs for UIData to require this behavior, but because this behavior is not currently
specified, I cannot include it in 2.0 Rev a. Therefore, I will move it to 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 ]

Set priority to Critical





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

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

Type: Bug Priority: Critical
Reporter: werpu12 Assignee: balusc
Resolution: Unresolved Votes: 55
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 mailinglist regarding this, since this is
a usecase which can happen quite often in a typical rich client szenario 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.





[JAVASERVERFACES_SPEC_PUBLIC-783] Unclear specification description for jsf.util.chain Created: 08/Apr/10  Updated: 01/Aug/14

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

Type: Bug Priority: Critical
Reporter: werpu12 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: 783
Status Whiteboard:

size_medium importance_large


 Description   

The current specification is very unclear regarding the parameters in the
jsf.util.chain functionality:

Here is the original quote:
jsf.util.chain(source, event)

A varargs function that invokes an arbitrary number of scripts.

<static> jsf.util.chain(source, event)

A varargs function that invokes an arbitrary number of scripts. If any script in
the chain returns false, the chain is short-circuited and subsequent scripts are
not invoked. Any number of scripts may specified after the event argument.

Parameters:
source
The DOM element that triggered this Ajax request, or an id string of the
element to use as the triggering element.
event
The DOM event that triggered this Ajax request. The event argument is optional.

There are several issues (some of them have been raised in the open list)

First of all it defines no return value so attaching functionality cannot
determine whether the chain has been processed fully or terminated only.
After asking in the eg it was more or less a consensous that the return value is
either true for having it processed fully or false otherwise, so that behaviors
can react properly.

Secondly, the entire parameter list aspect is rather unclear, first we have a
varargs function her, but it defines the event object as fixed object being
passed down, on the other hand it says it is optional.
So the description is clearly contradictory!

What was probably meant was that the event object must be passed down but its
values either can be an Event object or null or undefined!

therefore a call like chain(this, event, "alert..."
is valid
while a call like chain(this, "alert..." clearly is invalid
however a call like chain(this, null, "alert ..." ...

Have in mind that undefined, not always is an optional parameter in javascript,
but a full blown object of type 'undefined'!

The third issue is the term arbitrary number of scripts, a script can be two
things in javascript, either a string which later is evaluated (which is what
happens if you attach f:ajax, or it can be a function object which is passed
down which then later is executed.
I coded both cases into our myfaces chain, just to make sure the term arbitrary
is met, but this needs further clarification on the doc side as well!



 Comments   
Comment by Ed Burns [ 13/Apr/10 ]

2.1

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 29/Jun/10 ]

triage- get in for 2.1_gf31_m6

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 ]

Set priority to Critical





[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-1] multi-component validation Created: 16/Jul/04  Updated: 01/Aug/14

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

Type: Improvement Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 24
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days
Environment:

Operating System: All
Platform: All
URL: http://weblogs.java.net/pub/wlg/1625


Attachments: Zip Archive 1.zip     Text File changebundle.txt     PNG File radio buttons.png    
Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-626 Add standard way to modify browser hi... Open
depends on JAVASERVERFACES_SPEC_PUBLIC-1062 Non-Ajax File Upload Closed
Issuezilla Id: 1
Status Whiteboard:

EGTop5 effort_hard size_small importance_large


 Description   

Next spec should support multi-component validation.



 Comments   
Comment by Ed Burns [ 08/Dec/04 ]

move to 2.0

Comment by rdelaplante [ 05/Feb/08 ]

I will attach a screenshot to go with this comment:

I have a form where the validators for some fields depend on the submitted
values of other fields. For example, "re-enter e-mail address" needs to be
compared to the submitted value of "e-mail address". Both of these fields
should only be validated if "Send an email" radio button is selected. In my
validator code I use other components' getSubmittedValue() method which works
perfectly. getSubmittedValue has been deprecated, and the javadoc warns that it
should not be used. Why? If you take it out, I'll need to move the logic into
my action, and won't be able to "light up" the component's associated label to
indicate an error. One developer told me that this is an example of business
logic that belongs in an action. I disagree, this is validation logic that
belongs in the validator.

Comment by rdelaplante [ 05/Feb/08 ]

Created an attachment (id=121)
Form with multi field validators

Comment by rogerk [ 19/Aug/08 ]
      • Issue 60 has been marked as a duplicate of this issue. ***
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 52 has been marked as a duplicate of this issue. ***
Comment by mojavelinux [ 03/Nov/08 ]

I don't think that cross-field validation is a difficult problem to solve from
the specification level. The reason cross-field validation is difficult today is
because each field is converted individually, just prior to being validated.
Therefore, when the validate() method is called on a UIInput component, there is
no guarantee that any other component in the form will have been converted at
that time. It depends on the relative placement of the components in the form, a
fact which should not be relied on in a validator.

The current strategy puts the onus of having to convert the related field(s) on
the validator that is attempting to perform a cross-field check. Naive
developers will simply ignore the converters on that field. The developers that
do use the proper converter logic may still get sloppy with exception handling.
Refer to either the EqualityValidator in Seam or Tomahawk to witness the
ridiculous amount of code that must be used to handle all of these concerns
properly.

A better way to implement validation is to first convert all of the components
in the form. Once all the conversions are complete, then the validators run. An
extra walk of the component tree can be avoided by putting the input components
that were converted into an ordered collection (or map) and then iterating over
that collection (or map) to apply the validators. Using this suggested strategy,
implementing a multi-component validator is no more difficult than implementing
a validator on a single component. The validator tag would need to provide some
way to declaratively refer to the related components, such as by ID or value
expression.

Frankly, I don't feel it is the responsibility of the specification to create a
multi-component validator solution. What the specification should do is make it
easy to create such a solution. With that said, I do believe it would be a good
idea to implement a couple of basic multi-component validators to demonstrate 1)
how it's done and 2) the ease in which it can be done with conversion and
validation happening in distinct steps. Reference validators would include an
equality validator (one or more components), a greater and less than validator,
and perhaps a switch validator (a boolean component toggles the required flag on
another component).

Comment by rdelaplante [ 03/Nov/08 ]

> Frankly, I don't feel it is the responsibility of the specification to create
> a multi-component validator solution. What the specification should do is
> make it easy to create such a solution.

IMO JSF should come complete out of the box and not require additional
frameworks to make it usable unless it is some other JSR built into Java EE 6
application servers.

Comment by rdelaplante [ 22/Jan/09 ]

The following comment was added to Ed Burns' blog about this ticket:

Hello, we're looking to JSR-303 BeanValidation to help with this. In
fact, Emmanuel Bernard, has been doing an excellent job and we're fully
ready to include it in JSF 2.0 when the Java EE 6 platform group
approves it for inclusion.

Ed

Posted by: edburns on January 21, 2009 at 09:27 AM
http://weblogs.java.net/blog/edburns/archive/2009/01/jsf_20_public_r.html

Comment by rdelaplante [ 22/Jan/09 ]

John Reynolds wrote about an interesting idea [1] where JSF's h:form tag can
have validator(s) attached to it, like any other input component. The form could
validate the submitted values of any combination of components using business
rules, and throw a ValidatorException when there is a problem. That is how
Wicket does "business form"/multi component validation [2] and it seems that
this would be a simple addition to JSF 2.0 or 2.1. JSR-303 BeanValidation is
definitely welcome, but I think this idea is just as important for JSF.

[1] http://weblogs.java.net/blog/johnreynolds/archive/2004/07/improve_jsf_by_1.html
[2] http://cwiki.apache.org/WICKET/validating-related-fields.html

Comment by Ed Burns [ 04/Feb/09 ]

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

Comment by Ed Burns [ 04/Feb/09 ]

Created an attachment (id=198)
Zip of changed files, in lieu of checkin.

Comment by Ed Burns [ 04/Feb/09 ]

I have attached a fix for this bug, based on the new event system in JSF 2.0

Comment by Ed Burns [ 05/Feb/09 ]

Fixed enough for 2.0

Comment by Ed Burns [ 23/Mar/11 ]

Marked fixed, but I am not convinced it's actually committed.

Comment by kito75 [ 19/Apr/11 ]

Ed, correct me if I'm wrong, but isn't this patch just a specific use case rather than a generic solution?

I would expect something like this:

<f:validatorGroup name="insidePanel" validator="#

{myBean.validatePanel}

"/>
<h:inputText id="input1" validator="#

{myBean.validateInput1}

" validatorGroup="insidePanel"/>
<h:inputText id="input2" validatorGroup="insidePanel"/>

In this scenario, myBean.validatePanel() would be called, but sent in a Map<String, Object> of values, where String is the component id. validatePanel() wouldn't be called, however, unless myBean.validateInput1() executed successfully.

Comment by arjan tijms [ 28/May/11 ]

Such a validator group does sound like a nice idea. Optionally, you could loose the name if the components are nested:

<f:validatorGroup validator="#{myBean.validatePanel}">
   <h:inputText id="input1" validator="#{myBean.validateInput1}" />
   <h:inputText id="input2" />
</f:validatorGroup>

For general purpose multi-component validation, requiring the components to use a hard coded ID might be problematic. These IDs may already be needed for other purposes. So in that case perhaps f:validatorGroup can take f:param children to indicate this, or the proposed validatorGroup attribute could include some kind of designator, e.g.:

<f:validatorGroup name="insidePanel" validator="#{myBean.validatePanel}"/>
<h:inputText validator="#{myBean.validateInput1}" validatorGroup="insidePanel:input1"/>
<h:inputText validatorGroup="insidePanel:input2"/>
Comment by Mark Struberg [ 16/May/12 ]

Just a side note from the spectator seats:

  • doing 'easy' multi-field validations should be done via JSR-303
  • doing more complex multi-field validations are more likely part of the business logic and can be implemented in a JSF action method much more easily (and without any side-effects).
Comment by kito75 [ 17/May/12 ]

Depending on JSR-303 seems naive to me. A lot of people simply don't use it, and if you have an existing application it's prohibitively expensive to convert it (if not impossible, perhaps do to political constraints or time constraints).

So we need a solution that works within the JSF validation mechanism, and action methods don't cut it. I've seen a people use the postValidate event for this, which does work, but it's not very elegant. Something like what Seam-Faces has would work out fine: http://docs.jboss.org/seam/3/faces/reference/snapshot/en-US/html_single/#validateForm. I would want it to work without CDI, though.

This is a major whole in the JSF spec – I've seen people use different solutions on almost every project.

Comment by john_waterwood [ 17/Aug/12 ]

I hope its still posible to do this for JSF 2.2. Everyone now does this in their own way and it's such a basic thing. Anyone noticed this is issue nr 1? Would be great if it finally can be closed.

Comment by Ed Burns [ 26/Jun/13 ]

Still on the radar for 2.3.

Comment by rdelaplante [ 11/Jul/14 ]

OmniFaces has support for this feature:

http://showcase.omnifaces.org/validators/validateMultiple

I also like their other helpful validators such as <o:validateAll>, <o:validateAllOrNone>, <o:validateEqual>, <o:validateOne>, <o:validateOneOrMore>, <o:validateOneOrNone>, <o:validateOrder> or <o:validateUnique>

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. Lets get this one done!





[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-1203] Empty String as Null is not effective in 2.2.0 Created: 04/Jul/13  Updated: 20/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.2
Fix Version/s: None

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

glassfish 4.0, EL 3.0


Issue Links:
Related
is related to JAVASERVERFACES-3071 javax.faces.INTERPRET_EMPTY_STRING_SU... Closed
Tags: null, string

 Description   

GlassFish 4.0 uses EL 3.0.
Section 1.23.2 in EL 3.0 states that null String will be converted to empty String.
So we need a ELResolver to handle the conversion somethig like this

public class NullStringHanlder  extends ELResolver
{

	@Override
	public Class<?> getCommonPropertyType(ELContext context, Object base)
	{
		
		return String.class;
	}

	@Override
	public Iterator<FeatureDescriptor> getFeatureDescriptors(ELContext context,
			Object base)
	{
		return null;
	}

	@Override
	public Class<?> getType(ELContext context, Object base, Object property)
	{
		
		return null;
	}

	@Override
	public Object getValue(ELContext context, Object base, Object property)
	{
		
		return null;
	}

	@Override
	public boolean isReadOnly(ELContext context, Object base, Object property)
	{
		
		return true;
	}

	@Override
	public void setValue(ELContext context, Object base, Object property,
			Object value)
	{
		
		
	}

	@Override
	public Object convertToType(ELContext context, Object obj,
			Class<?> targetType)
	{
		if (obj==null && String.class.equals(targetType))
		{
			context.setPropertyResolved(true);;
			return null;
		}
		return null;
			
		
	}
	

}




 Comments   
Comment by Ed Burns [ 05/Jul/13 ]

Thanks for taking the time to report this. How do you suggest we reconcile this issue with the meaning of the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context-param? This param is described in section 11.1.3 Application Configuration Parameters of the spec.

javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL – If this param is set, and calling toLowerCase().equals("true") on a String representation of its value returns true, any implementation of UIInput.validate() must take the following additional action.
If the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context parameter value is true (ignoring case), and UIInput.getSubmittedValue() returns a zero-length String call UIInput.setSubmittedValue(null) and continue processing using null as the current submitted value

Comment by jasonzhang2002gmailcom [ 05/Jul/13 ]

This is integration issue. Mojarra definitely follows the specification. However, the problem is deeply down into EL implementation/Spec. I am currently using a custom ELResolver(see above) only for this string conversion. By this way, no mojarra or EL is effected. Mojarra can come with such a resolver to explicitly to control the string conversion by default.

Comment by Ed Burns [ 08/Jul/13 ]

We need to move this to the spec issue tracker because what you are asking is a spec change. We understand that EL 3.0 allows this, but we would need to bring this issue up to the expert group.

Comment by rekiem87 [ 10/Apr/14 ]

Glassfish 4.0.1 with the latest mojarra still have the issue

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-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} Open
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1387 Let CDI handle #{header} Open
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1388 Let CDI handle #{headerValues} Open
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1389 Let CDI handle #{initParam} Open
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1390 Let CDI handle #{param} Open
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1391 Let CDI handle #{paramValues} Open
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1392 Let CDI handle #{request} Open
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1393 Let CDI handle #{requestScope} Open
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1394 Let CDI handle #{resource} Open
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-1396] Standardize WebSocket and SSE integration with f:socket Created: 12/Aug/15  Updated: 20/Aug/15

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: None
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: 0 minutes
Time Spent: 1 hour, 8 minutes
Original Estimate: Not Specified





[JAVASERVERFACES_SPEC_PUBLIC-1202] cc:attributes type attribute: fallback case: use what the ELResolver returns. Created: 03/Jul/13  Updated: 20/Aug/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: Manfred Riem
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-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-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-1355] Parameterize Object argument in Converter and Validator interfaces Created: 30/Jan/15  Updated: 21/Aug/15

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

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

Attachments: Text File changebundle-part-revert.txt     Text File changebundle-revert-all.txt     Text File changebundle.txt     Java Source File DateTimeConverter.java     Zip Archive newfiles.zip    

 Description   

All Converter and Validator implementations need to cast Object to T of interest. This is unnecessarily clumsy. Change Object to T in Converter and Validator interfaces.

public interface Converter<T> {
  public T getAsObject(FacesContext contect, UIComponent component, String submittedValue);
  public String getAsString(FacesContext contect, UIComponent component, T modelValue);
}
public interface Validator<T> {
  public void validate(FacesContext contect, UIComponent component, T value);
}


 Comments   
Comment by arjan tijms [ 30/Jul/15 ]

Applied to 2.3 trunk:
svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1355, generics in converter and validator, r=mriem"
Sending jsf-api/src/main/java/javax/faces/convert/BigDecimalConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BigIntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BooleanConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ByteConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/CharacterConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/Converter.java
Sending jsf-api/src/main/java/javax/faces/convert/DateTimeConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DoubleConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/EnumConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/FloatConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/IntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/LongConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/NumberConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ShortConverter.java
Sending jsf-api/src/main/java/javax/faces/validator/BeanValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/DoubleRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LengthValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LongRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/MethodExpressionValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RegexValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RequiredValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/Validator.java
Sending jsf-ri/test/com/sun/faces/application/TestApplicationImpl.java
Sending test/servlet30-isolated/cactus/src/main/java/com/sun/faces/application/TestApplicationImpl.java
Adding test/unit/src/test/java/javax/faces/validator/CastingValidatorTestCase.java
Transmitting file data .........................
Committed revision 14952.

Comment by arjan tijms [ 30/Jul/15 ]

Reverting commit, tests don't pass.

svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1355, reverse, servlet30/systest failing"
Sending jsf-api/src/main/java/javax/faces/convert/BigDecimalConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BigIntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BooleanConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ByteConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/CharacterConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/Converter.java
Sending jsf-api/src/main/java/javax/faces/convert/DateTimeConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DoubleConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/EnumConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/FloatConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/IntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/LongConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/NumberConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ShortConverter.java
Sending jsf-api/src/main/java/javax/faces/validator/BeanValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/DoubleRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LengthValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LongRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/MethodExpressionValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RegexValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RequiredValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/Validator.java
Sending jsf-ri/test/com/sun/faces/application/TestApplicationImpl.java
Sending test/servlet30-isolated/cactus/src/main/java/com/sun/faces/application/TestApplicationImpl.java
Deleting test/unit/src/test/java/javax/faces/validator/CastingValidatorTestCase.java
Transmitting file data ........................
Committed revision 14953.

Comment by Manfred Riem [ 10/Aug/15 ]

Look good r=mriem

Comment by arjan tijms [ 10/Aug/15 ]

Applied to 2.3 trunk:
svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1355, generics in converter and validator with fixed test, r=mriem"
Sending jsf-api/src/main/java/javax/faces/convert/BigDecimalConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BigIntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BooleanConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ByteConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/CharacterConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/Converter.java
Sending jsf-api/src/main/java/javax/faces/convert/DateTimeConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DoubleConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/EnumConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/FloatConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/IntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/LongConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/NumberConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ShortConverter.java
Sending jsf-api/src/main/java/javax/faces/validator/BeanValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/DoubleRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LengthValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LongRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/MethodExpressionValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RegexValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RequiredValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/Validator.java
Sending jsf-ri/test/com/sun/faces/application/TestApplicationImpl.java
Sending test/servlet30/systest/src/main/java/com/sun/faces/systest/model/EnumBean.java
Sending test/servlet30/systest/src/main/webapp/enum-converter-1.jsp
Sending test/servlet30-isolated/cactus/src/main/java/com/sun/faces/application/TestApplicationImpl.java
Adding test/unit/src/test/java/javax/faces/validator/CastingValidatorTestCase.java
Transmitting file data ...........................
Committed revision 14983.

Comment by arjan tijms [ 12/Aug/15 ]

A concern was raised that Mojarra's own provided Converters and a single Validator weren't totally backwards compatible anymore for the perhaps rare but possible case where someone would assign say a BigDecimal to a variable of type Object and feed that into the getAsString method of a BigDecimalConverter.

With the new tyfe-safe change such usage would not compile anymore. Therefor largely reverted the changes to the provided Converters/Validator, but kept the changes to the Interfaces, since legacy code would have a raw version of these, which are compatible by design.

Applied to 2.3 trunk:
svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1355, partially reverted Mojarra’s converters/validators for backwards compatibility. Only interfaces themselves typesafe. r=mriem"
Sending jsf-api/src/main/java/javax/faces/convert/BigDecimalConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BigIntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BooleanConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ByteConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/CharacterConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DateTimeConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DoubleConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/FloatConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/IntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/LongConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/NumberConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ShortConverter.java
Sending jsf-api/src/main/java/javax/faces/validator/DoubleRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LengthValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LongRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RegexValidator.java
Sending jsf-ri/test/com/sun/faces/application/TestApplicationImpl.java
Sending test/servlet30-isolated/cactus/src/main/java/com/sun/faces/application/TestApplicationImpl.java
Transmitting file data ..................
Committed revision 14994.

Comment by Ed Burns [ 17/Aug/15 ]

Hello Arjan,

I'm still having problems running our ADF automated tests against
mojarra 2.3 trunk since your generics changes to
javax.faces.convert.Converter. Here is the compilation failure message:

8<------------------

[otranslate] wptgFile = /ade/aime_slc08ydi/oracle/built/trinidad-api/src-wptg.txt
[echo] Response file /ade/aime_slc08ydi/oracle/built/trinidad-api/src-javac.rsp
[echo] Compiling with out-of-process JAVAC
[java] Compiling 477 sources
[java] Error: /ade/aime_slc08ydi/jdevadf/modules/trinidad-api/etc/src/main/java/org/apache/myfaces/trinidad/convert/DateTimeConverter.java(178,8): javax.faces.convert.Converter cannot be inherited with different arguments: <> and <java.lang.Object>
[java] Some input files use or override a deprecated API.
[java] Recompile with -Xlint:deprecation for details.
[java] Some input files use unchecked or unsafe operations.
[java] Recompile with -Xlint:unchecked for details.
[java] Compilation time: 4978 msec, cdi generation time: 4759 msec.
[java] 1 error, 0 warnings
Scanned 22326 files and directories in 341ms: 0 files added, 0 files
removed, 0 directories added, 0 directories removed

8<------------------

I've attached the failing file so you can see what's going on. This is
from the Apache trinidad JSF Component library.

Can you please make the necessary changes so the attached compiles with
JSF 2.3?

Thanks,

Ed

Comment by arjan tijms [ 18/Aug/15 ]

Now reverted all provided Converters and Validators completely.

Problem was that a somewhat questionable but possible construct appeared in the wild, where a class would both extend a Converter implementation (e.g. DateTimeConverter and then also implement Converter separately (which is not needed, since the class from which is inherited already implements this interface). With the <Object> added to the super class, the two Converter implementations would be different; effectively parameterized with <Object> vs raw. Unfortunately this does not compile.

svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1355, completely reverted Mojarra’s converters/validators for backwards compatibility. Only interfaces themselves typesafe. r=mriem"
Sending jsf-api/src/main/java/javax/faces/convert/BigDecimalConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BigIntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/BooleanConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ByteConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/CharacterConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DateTimeConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/DoubleConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/EnumConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/FloatConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/IntegerConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/LongConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/NumberConverter.java
Sending jsf-api/src/main/java/javax/faces/convert/ShortConverter.java
Sending jsf-api/src/main/java/javax/faces/validator/BeanValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/DoubleRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LengthValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/LongRangeValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/MethodExpressionValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RegexValidator.java
Sending jsf-api/src/main/java/javax/faces/validator/RequiredValidator.java
Transmitting file data ....................
Committed revision 15020.





[JAVASERVERFACES_SPEC_PUBLIC-1356] Explicitly specify and document UIInput#processValidators() behavior as to component's children Created: 30/Jan/15  Updated: 21/Aug/15

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

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


 Description   

In Mojarra, the processValidators() is first executed on the UIInput component itself and then on its facets/children. But in MyFaces, the processValidators() is first executed on the UIInput component's facets/children and then on itself. Exactly the other way round.

The desired behavior is as of now nowhere explicitly specified in the spec. It should be specified and aligned out.






[JAVASERVERFACES_SPEC_PUBLIC-1380] Utilize @FacesDataModel for existing DataModel wrappers Created: 19/Jul/15  Updated: 21/Aug/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: 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-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-559] Support for the "Synchronizer Token" pattern (avoiding double submits) Created: 05/May/09  Updated: 24/Aug/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.





[JAVASERVERFACES_SPEC_PUBLIC-1298] Resolve backward incompatible change regarding PartialResponseWriter.writePreamble() Created: 11/Aug/14  Updated: 24/Aug/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: Manfred Riem
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-1316] Support @Inject on JSF artifacts Created: 09/Oct/14  Updated: 24/Aug/15

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: Not Specified
Time Spent: Not Specified
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.





[JAVASERVERFACES_SPEC_PUBLIC-1150] Add @ClientWindowScoped Created: 04/Dec/12  Updated: 20/Aug/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: Unassigned
Resolution: Unresolved Votes: 1
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.





[JAVASERVERFACES_SPEC_PUBLIC-984] Component context management Created: 21/Apr/11  Updated: 25/Aug/15

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

Type: New Feature Priority: Critical
Reporter: aschwart Assignee: aschwart
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 15 minutes
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    
Issue Links:
Dependency
depends on JAVASERVERFACES-2272 Implement ComponentModificationManager Closed
Status Whiteboard:

size_large importance_large


 Description   

CA fairly common pattern in JSF is for container components to temporarily set up context that is available while processing children - eg. UIData sets up the "var" value before executing child lifecycle methods. In Trinidad and ADF Faces we have a variety of components that establish similar context.

An issue with this is that there is no way to unwind/suspend this context in cases where it is necessary to interrupt processing in order to start over in a new context - eg. when invokeOnComponent() or visitTree() is called.

Trinidad has solved this problem via its ComponentContextManager API. See:

http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/context/ComponentContextManager.java?view=markup

This provides a common mechanism that components can use for pushing/popping/suspending their context and allows for new invokeOnComponent()/visitTree() calls to be initiated in a clean environment.

In addition, Trinidad's UIXComponent provides a number of hooks to assist components with their context setup/teardown.

One problem with Trinidad's solution is that it only applies to Trinidad-based components. Ideally this problem should be solved by the JSF specification in a generic manner so that all components can participate.



 Comments   
Comment by Ed Burns [ 02/Nov/11 ]

Carry forward to 2.2 Sprint 9.

Comment by Ed Burns [ 16/Dec/11 ]

Andy, can you please verify my understanding? Have I got this right:

You are not suggesting that we implement this API and, at the same time, modify
invokeOnComponent() and visitTree() to automatically perform the spend/resume using
the API?

In other words:

This proposal seeks to provide an API that components can use themselves when they need
to be able to temporarily suspend their processing in order to correctly perform
a invokeOnComponent() or visitTree() operation. There will be no occurrences of using
this API in the standard components.

Is that correct?

Comment by Ed Burns [ 16/Dec/11 ]

First draft of API committed to trunk.

Adding jsf-api/src/main/java/javax/faces/component/visit/ComponentModification.java
Adding jsf-api/src/main/java/javax/faces/component/visit/ComponentModificationManager.java
Sending jsf-api/src/main/java/javax/faces/context/FacesContext.java
Sending jsf-api/src/main/java/javax/faces/context/FacesContextWrapper.java
Sending jsf-ri/src/main/java/com/sun/faces/context/FacesContextImpl.java
Transmitting file data .....
Committed revision 9521.

Comment by Ed Burns [ 14/Mar/13 ]

Re-opening per Andy's request.

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-1370] Provide Converters for Java 8 Date and Time API (JSR 310) Created: 01/May/15  Updated: 25/Aug/15

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

Type: New Feature Priority: Critical
Reporter: codylerum Assignee: javajuneau
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-1272 Take advantage of Java SE 8 JSR-310 T... Closed

 Description   

Apologies if I have missed an existing issue but I'm trying to determine how the convertDateTime converters will be aligned to support Java 8 Date and Time API in JSF 2.3



 Comments   
Comment by codylerum [ 01/May/15 ]

I meant to do this as a SPEC issue. Can it be moved?

Comment by Manfred Riem [ 01/May/15 ]

Done

Comment by Ed Burns [ 18/Aug/15 ]

Yes, this is a must for JSF 2.3.

EG member Josh Juneau wrote a blog post about it, but to actually get it in the spec we need a lot more work: < http://www.javacodegeeks.com/2015/06/utilizing-the-java-8-date-time-api-with-jsf-and-java-ee-7.html >.

Comment by Ed Burns [ 18/Aug/15 ]

Some questions about putting this in the spec.

1. What do we need to say in section 3.3.3 Standard Converter Implementations?

2. Which of java.time.

{LocalDate,LocaleTime,LocalDateTime}

do we want to support? All of them I'd think, but how does this square with the JSF conversion model which seems to favor the combined "DateTime" concept.

3. Perhaps we should create a new converter along side DateTimeConverter, say JavaTimeDateTimeConverter and trick it out with lots of attributes as the current DateTimeConverter does?





[JAVASERVERFACES_SPEC_PUBLIC-1066] JavaDoc for Application#getNavigationHandler() method does not mention the navigation-handler within the application element of faces-config Created: 26/Jan/12  Updated: 26/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0, 2.1, 2.0 Rev a, 2.1 Rev a, 2.2 Sprint 1, 2.2 Sprint 2, 2.2 Sprint 3, 2.2 Sprint 4, 2.2 Sprint 5, 2.2 Sprint 6, 2.2 Sprint 7, 2.2 Sprint 8, 2.2 Sprint 9
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Neil Griffin Assignee: Neil Griffin
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-1072 Add javax.faces.application.Navigatio... Closed

 Description   

There is a documentation bug/omission in the JSF 2.0/2.1 JavaDoc. Specifically, the omission is that the Application#getNavigationHandler() method [1] is supposed to let you specify a wrappable implementation from the <navigation-handler> within the <application> element of faces-config. The feature is formally specified in the faces-config XML Schema [2]. I just checked and both Mojarra [3] and MyFaces [4] implement this feature.

Please refer to the Application#getResourceHandler() method [5] for an example of how to describe this feature in JavaDoc.

[1] http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/application/Application.html#getNavigationHandler()
[2] http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd
[3] com.sun.faces.config.processor.ApplicationConfigProcessor
[4] org.apache.myfaces.config.element.Application
[5] http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/application/Application.html#getNavigationHandler()



 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-1080] New Component APIs to manage EL context as it applies to components. Created: 05/Mar/12  Updated: 26/Aug/15

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

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Manfred Riem
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: 6 days, 17 hours, 47 minutes
Time Spent: 6 hours, 13 minutes
Original Estimate: 1 week

Attachments: Text File 20120316-1025-i_spec_1080.patch     Text File 20120319-1714-i_spec_1080.patch    
Issue Links:
Dependency
depends on UEL-29 Make it possible to be notified when ... Open
Tags: adf_high

 Description   

B> The issue with clientIds is that portions of the clientId are an
B> implementation detail of the components and renderkit. The result is
B> that developers are not supposed to be hardcoding clientIds into their
B> code. Developers need a different kind of id that specifies context
B> like a clientId, but is standardized like a findComponent search
B> expression. Let's call this a contextId.

B> Given a contextId, we would like to be able to do the following:
B> 1) Efficiently convert the contextId into an object capable of
B> establishing and tearing down the context for the component relatively
B> efficiently. This would require new component apis.
B> 2) Add a function like findComponentInContext that may return a proxy
B> for the UIComponent executing in the context object from 1)
B> 3) Since setting up and tearing down context on every attribute
B> retrieval is inefficient--framework managed context so that the current
B> context may be torn down lazily.



 Comments   
Comment by Ed Burns [ 20/Mar/12 ]

I tried implementing the testing logic, but it became too complex and I decided it's not worth the trouble.

Sending jsf-api/src/main/java/javax/faces/component/UIComponent.java
Sending nbproject/project.xml
Transmitting file data ..
Committed revision 9769.

A better use of my time is to try to implement the API that Blake mentioned from Trinidad ComponentContextManager.

Ed

Comment by Manfred Riem [ 20/Mar/12 ]

Ed,

The latest commit for this issue broke the trunk build. When can we expect a resolution on this?

Manfred

Comment by Ed Burns [ 21/Mar/12 ]

http://adc2120535.us.oracle.com:7070/hudson/view/Jobs%20for%20Ed/job/mojarra-trunk-glassfish-3_1_2-no-cluster-systest/80/

Seems to be blue, and it's from r9772.

http://adc2120535.us.oracle.com:7070/hudson/view/Jobs%20for%20Ed/job/mojarra-trunk-glassfish-3_1_2-no-cluster-systest/78/

Is also blue, and that's from r9769.

Can you please point me to the failing job?

I'll fix it right away, of course.

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-1244] Reword requirements for EL expressions inlined in Facelets pages, but outside of components. Created: 19/Dec/13  Updated: 26/Aug/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: Manfred Riem
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-1225] What to say about BCP47 Support? Created: 02/Oct/13  Updated: 26/Aug/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: Manfred Riem
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-1210 Account for BCP47 Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1245 Section "Determining the active Local... Open

 Description   

BCP47 defines new rules for the parsing of Locale objects. These rules are implemented in the java.util.Locale class in JDK7. There are several places in the JSF spec that place requirements on how a Locale is encoded as a String.

  • XSD for supported-locale
  • XSD for default-locale
  • Spec section "2.5.2.1 Determining the Active Locale" in the portion of that section that deals with the locale attribute on the <f:view> tag.

In all of these places statements are made regarding the use of "-" or "_" as a separator. This issue asks if we should go further and require the use of JDK7 Locale.forLanguageTag() to obtain the Locale instance before trying the existing methods of obtaining a Locale.



 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-1245] Section "Determining the active Locale" includes too narrow language Created: 26/Dec/13  Updated: 26/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Manfred Riem
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_SPEC_PUBLIC-1225 What to say about BCP47 Support? Open

 Description   

There is text in section "Determining the active Locale" (section number 2.5.2.1 as of version 2.2 of the JSF spec) that speaks too narrowly of how the system must process the <supported-locale> entries in the <locale-config> of the faces-config.xml file. In particular, this text runs afoul of the changes for script tags specified in IETF BCP47.

This text must be generalized so that existing behavior continues to be spec compliant, while BCP47 style entries can also be supported.

The spec for the <f:view locale> attribute must also be inspected so that it is compatible with BCP47.



 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-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: 26/Aug/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: Manfred Riem
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-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-1107] Use VDLDoc tool for spec Facelets VDLDoc sections Created: 30/May/12  Updated: 26/Aug/15

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

Type: Task Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 9 hours, 5 minutes
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1106 Content of ui.taglib.xml Open

 Description   

Use output of JAVASERVERFACES-974 to generate Facelets VDLDoc.



 Comments   
Comment by Ed Burns [ 21/Feb/13 ]

Edward Burns wrote on 02/19/2013 08:38 AM:

EB> Also, until we upgrade the JSF build system away from tlddoc, and jsdoc
EB> (which doesn't support any kind of "bottom" option) and the home-grown
EB> renderkitdoc tool (which also doesn't support such a thing) the
EB> non-javadoc, non-pdf portions of the spec will not have this notice. If
EB> this is a problem, we need to allocate time to solve it.

>>>>> On Wed, 20 Feb 2013 20:39:08 -0800, Bill Shannon said:

B> We've lived with this for years and years so I wouldn't consider it high
B> priority, but please do add it to your list of issues to address.

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 Minor

Comment by Manfred Riem [ 21/May/15 ]

Can you please isolate it to one ant target so the migration later on will be easier. Thanks!

Comment by Ed Burns [ 26/May/15 ]

M jsf-api/src/main/java/javax/faces/application/ApplicationConfigurationPopulator.java
M jsf-api/src/main/java/javax/faces/application/ProjectStage.java
M jsf-api/src/main/java/javax/faces/flow/FlowHandler.java
M jsf-api/src/main/java/javax/faces/flow/builder/NavigationCaseBuilder.java
M jsf-api/src/main/java/javax/faces/flow/builder/MethodCallBuilder.java
M jsf-api/src/main/java/javax/faces/flow/builder/SwitchCaseBuilder.java
M jsf-api/src/main/java/javax/faces/flow/builder/ReturnBuilder.java
M jsf-api/src/main/java/javax/faces/flow/builder/SwitchBuilder.java
M jsf-api/src/main/java/javax/faces/flow/builder/FlowCallBuilder.java
M jsf-api/src/main/java/javax/faces/flow/builder/NodeBuilder.java
M jsf-api/src/main/java/javax/faces/flow/builder/FlowBuilder.java
M jsf-api/src/main/java/javax/faces/view/BehaviorHolderAttachedObjectHandler.java
M jsf-api/src/main/java/javax/faces/view/AttachedObjectHandler.java
M jsf-api/src/main/java/javax/faces/view/facelets/AttributeHandler.java
M jsf-api/src/main/java/javax/faces/view/facelets/TagConfig.java
M jsf-api/src/main/java/javax/faces/view/facelets/FaceletsAttachedObjectHandler.java
M jsf-api/src/main/java/javax/faces/view/facelets/BehaviorConfig.java
M jsf-api/src/main/java/javax/faces/context/Flash.java

  • Fix javadoc errors and broken links.
    Sending jsf-api/src/main/java/javax/faces/application/ApplicationConfigurationPopulator.java
    Sending jsf-api/src/main/java/javax/faces/application/ProjectStage.java
    Sending jsf-api/src/main/java/javax/faces/context/Flash.java
    Sending jsf-api/src/main/java/javax/faces/flow/FlowHandler.java
    Sending jsf-api/src/main/java/javax/faces/flow/builder/FlowBuilder.java
    Sending jsf-api/src/main/java/javax/faces/flow/builder/FlowCallBuilder.java
    Sending jsf-api/src/main/java/javax/faces/flow/builder/MethodCallBuilder.java
    Sending jsf-api/src/main/java/javax/faces/flow/builder/NavigationCaseBuilder.java
    Sending jsf-api/src/main/java/javax/faces/flow/builder/NodeBuilder.java
    Sending jsf-api/src/main/java/javax/faces/flow/builder/ReturnBuilder.java
    Sending jsf-api/src/main/java/javax/faces/flow/builder/SwitchBuilder.java
    Sending jsf-api/src/main/java/javax/faces/flow/builder/SwitchCaseBuilder.java
    Sending jsf-api/src/main/java/javax/faces/view/AttachedObjectHandler.java
    Sending jsf-api/src/main/java/javax/faces/view/BehaviorHolderAttachedObjectHandler.java
    Sending jsf-api/src/main/java/javax/faces/view/facelets/AttributeHandler.java
    Sending jsf-api/src/main/java/javax/faces/view/facelets/BehaviorConfig.java
    Sending jsf-api/src/main/java/javax/faces/view/facelets/FaceletsAttachedObjectHandler.java
    Sending jsf-api/src/main/java/javax/faces/view/facelets/TagConfig.java
    Transmitting file data ..................
    Committed revision 14778.

In progress.

Comment by Ed Burns [ 22/Jul/15 ]

VDLDoc with -f -css showing -css isn't fully supported.





[JAVASERVERFACES_SPEC_PUBLIC-613] Support standard AJAX server-side method invocation Created: 15/Aug/09  Updated: 01/Sep/15

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

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

Operating System: Linux
Platform: PC
URL: http://docs.jboss.org/richfaces/latest_3_3_X/en/tlddoc/a4j/jsFunction.html


Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-672 Allow Ajax Listener for jsf.ajax.request Closed
Issuezilla Id: 613
Status Whiteboard:

cat2 frame size_medium importance_large draft


 Description   

> Almost every AJAX framework I know of allows you to
> simply execute a method on the server side, with or without params,
> and return a result.

JSF should support this behavior. Use cases include:

  • Calling a server-side method to return values used to control page behavior.
  • Calling a server side method to submit data to the application, returning
    success, failure, or nothing to the UI.

This functionality is already part of the JBoss Ajax4JSF framework, every PHP
ajax framework, and every non-server tech-specific framework (such as Dojo,
Prototype, etc..)

See A4J:jsFunction component –
http://docs.jboss.org/richfaces/latest_3_3_X/en/tlddoc/a4j/jsFunction.html



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

Sure, I'll entertain this.

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 25/Sep/09 ]

Retarget to 2.next

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 lincolnbaxter [ 26/Jan/10 ]

Categorized as part of Rev 2.0 A prep

Comment by rogerk [ 05/Mar/10 ]

cat2 - yes - this would be nice!

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 Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 01/Jul/10 ]

re-target

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 priority to Critical





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

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

Type: Improvement Priority: Critical
Reporter: rdelaplante Assignee: cagatay_civici
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.





[JAVASERVERFACES_SPEC_PUBLIC-1321] Leverage HTTP2 Server Push from JSF Created: 13/Oct/14  Updated: 01/Sep/15

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.






[JAVASERVERFACES_SPEC_PUBLIC-1056] More flexible state saving Created: 30/Nov/11  Updated: 01/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: Manfred Riem
Resolution: Unresolved Votes: 14
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: state, state_saving_method

 Description   

In JSF the user can choose to save state on the server or the client via the javax.faces.STATE_SAVING_METHOD context parameter. Because this is a global setting that applies to all views in the application, it's not really flexible.

I would like to propose making this more flexible. Ideally the user would have three options for state: none (see JAVASERVERFACES_SPEC_PUBLIC-1055), client and server and would be able to set this globally, per URL pattern, or per view.

Setting the state saving method on a view would override any setting done per URL pattern, and setting state saving for a URL pattern overrides the global setting.



 Comments   
Comment by Ed Burns [ 01/Feb/12 ]

Although this would be very useful, we have to leave this as Fix Version unknown because I haven't figured out yet how to fit it into JSF 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.





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-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-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-1098] f:ajax exeucte always sends all the fields of the wrapping form Created: 08/May/12  Updated: 13/Aug/14

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

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


 Description   

f:ajax doesn't obey the 'execute' attribute but always sends all the fields in a form. Mojarra does, however, only process the listed fields as supposed. However, excess fields shouldn't be sent because it increases request size.

Recplicate with:

<h:form id="form1">
<h:commandButton>
<h:inputText id="field1" />
<h:inputText id="field1x" />
<f:ajax execute="field1" />
</h:commandButton>
</h:form>

On button click, both fields are sent (but only field1 would be processed).

See for further info: http://stackoverflow.com/questions/3889894/jsf-2-0-why-does-fajax-send-all-the-form-fields-and-not-only-those-marked-with

See: http://java.net/jira/browse/JAVASERVERFACES-1908



 Comments   
Comment by Darious3 [ 18/Aug/12 ]

PrimeFaces has recently implemented this, would be great to have this in the spec.

Comment by kithouna [ 28/Jan/13 ]

Must have feature for JSF 2.3. This really shouldn't be that hard, should it?

Comment by arjan tijms [ 31/Jan/13 ]

An implementation duplicate: JAVASERVERFACES-1841

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

 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-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-939] behavior issues with "INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL" setting 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: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-3098 Regression in UIComponentBase#saveAtt... Closed
Status Whiteboard:

size_medium importance_medium


 Description   

currently - where INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is FALSE - we
have the following behavior:

Imaging two elements, bound to some managed bean (e.g in sessionScope)

<inputText id="one" />
<inputText id="two" required="true" />

Enter this:
one => FOO
two => BAR
HIT_ENTER (e.g submit the form)

now remove all the values
one =>
two =>
HIT_ENTER (e.g submit the form)

the rendered result is that BOTH fields are empty and there is an error-msg
for the required one.

Now when "INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL" is set to TRUE, we
have the following behavior
(same components used):

Enter this:
one => FOO
two => BAR
HIT_ENTER (e.g submit the form)

now remove all the values
one =>
two =>
HIT_ENTER (e.g submit the form)

the rendered result is that ONLY the required field is empty (and it has a
warning msg).
The other one - b/c submitted value is NULL is getting the real value, which has
been pushed into the bean before (=>FOO)

=> Is this really the intention ?

Do we really want to show the "original" data ? Today we don't, we just provided
the entered stuff/wrong_value (e.g nothing in this particular case)

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=mwessendorf%40java.net):

ah, ok.

basically the fix is this:

public Object getValue()
{
FacesContext fc = getFacesContext();
if (fc != null && fc.isValidationFailed())

{ return getStateHelper().get(PropertyKeys.value); }

else

{ return getStateHelper().eval(PropertyKeys.value); }

}

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=mwessendorf%40java.net):

IMO you shouldn't return something different from getValue because validation
failed!

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=rlubke):

It's returning the local value that would have been pushed to the model if
validation hadn't failed. That behavior seems correct based on the problem report.

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=gabfest):

let's say validation doesn't fail, but for some reason the developer calls
renderResponse in a valueChangeListener. Shouldn't the local value still get
shown when you rerender?
[ Show » ]
gabfest added a comment - 02/Dec/09 11:16 AM let's say validation doesn't fail, but for some reason the developer calls renderResponse in a valueChangeListener. Shouldn't the local value still get shown when you rerender?

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=rlubke):

Fair point.



 Comments   
Comment by vabp [ 15/May/12 ]

Can this please be addressed? It is significantly impact our in-production system.

Comment by balusc [ 11/Oct/12 ]

Issue 2262 is related http://java.net/jira/browse/JAVASERVERFACES-2262

Comment by dennishoersch [ 14/Jan/13 ]

Is there any decision made?

We're using the 'interpretion' of a submitted value as null, but the redisplay of the old value is a problem for us 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-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-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





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





[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-1299] jsf.ajax.response should not send 'success' events in case of an error Created: 14/Aug/14  Updated: 14/Aug/14

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

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


 Description   

This is a followup of JAVASERVERFACES-3103.

If the ajax response contains an error the clientside JS (jsf.ajax.response) sends an "serverError" event to the registered listeners AND just after this an "success" event to registered listeners. This leads to malfunctions if the application depends on both of these events. The "success" event is unexpected in the server side error (e.g. Exception in the triggered ajax listener) case here.

jsf.js
line 2255: sendError(request, context, "serverError", null, errorName, errorMessage);
line 2256: sendEvent(request, context, "success");

At the moment this behavior is by design but it does not make sense:
Two concerns are mixed up here: processing the response on the client side and processing the request on the server side.

The response is indeed successfully processed on the client side. But the client side does not need to be notified by this explicitly in that case. The processed result is already available in the onerror event handler.
There is no more information available in the "success" event and this behaviour makes it complicated to handle server side errors on the client.

For the enduser the result of a failed processed request or a successfully proccessed server side error is the same: there is an error not a successfully performed action.

So how can one dedect a "success" event in a server error case at the moment:

  • explicitly analyse the data transmitted
  • remember there was already an error event before

Both options are not necessary if the spec would not require to send the "success" event in a server error case.

Manfred Riem agrees with me.






[JAVASERVERFACES_SPEC_PUBLIC-1281] Extend vdl.createComponent with support of ui:includes and user tags Created: 31/May/14  Updated: 21/Aug/14

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

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


 Description   

Myfaces implementation extends their vdl.createComponent with support of ui:include and custom or composite tags. This great solution completely replace a set of strange workarounds from network or OpenFaces.

Mojarra in vdl.createComponent and DefaultFaceletFactory._createComponent supports only standard UIComponents and tags from api. There is no reason to support only tags from api.
Problem was registered as https://java.net/jira/browse/JAVASERVERFACES-3281 but unfortunately closed.

Test examples
-mojarra-2.2.6\test\agnostic\component\programmaticComponentCreation\src\main\java\com\sun\faces\test\agnostic\component\programmaticComponentCreation\CreateComponentBean.java
-http://svn.apache.org/repos/asf/myfaces/core/trunk\impl\src\test\java\org\apache\myfaces\view\facelets\pool\
-http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/test/java/org/apache/myfaces/view/facelets/pss/acid



 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

Comment by krokodylowy3 [ 21/Aug/14 ]

This extension is also performance improvement. We no longer need use a set of permanent includes and tags for temporary visible popups and views which was a old headache of jsf framework. Code can be truly dynamic and well separated.





[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


 Description   

See the RequiredCheckboxValidator in OmniFaces for a discussion of the issue:

http://showcase.omnifaces.org/validators/RequiredCheckboxValidator

The default behavior in JSF is non-intuitive and causes seemingly unnecessary work to be required in the action 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.

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: