[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-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-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-613] Support standard AJAX server-side method invocation Created: 15/Aug/09  Updated: 20/Aug/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: Manfred Riem
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-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-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-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-1227] Add <f:protectClientWindowOpenInNewTab> JavaScript behavior tag Created: 07/Oct/13  Updated: 01/Aug/14

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

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


 Description   

With the introduction of ClientWindow in JSF 2.2, it's possible to protect against multiple tabs being open on the same view. However, components that render links allow the user to do "open in new tab" or "open in new window". This can cause a situation where there are multiple tabs that still have the same ClientWindow, which is incorrect.

This feature proposal asks for the creation of a ClientBehavior tag that, when nested inside of a component that renders as a link, will make it so a new client window is created when the link is clicked.



 Comments   
Comment by Ed Burns [ 07/Oct/13 ]

Here's a sketch for how this could work.

Here's how you'd use it.

<h:link outcome="callB" value="Call B via GET">
<f:protectClientWindowOpenInNewTab />
</h:link>

This would cause the link to be rendered with some javascript that listens for an onclick on the link. In the handler, check if the right mouse button was pressed and take appropriate action.

Comment by Thomas Asel [ 08/Oct/13 ]

I am afraid that this feature would force unintuitive behavior and also advocates a rather patronizing development style.

How about creating a client behavior that creates a window id on demand?
So instead of blocking the contextmenu we could use the oncontextmenu handler to create a new id and append it as a parameter to the link.

Comment by Ed Burns [ 08/Oct/13 ]

Thanks for the feedback, Thomas. We can certainly change the name to be less patronizing.

Please note that the ClientWindow will be created on demand when the request comes in without having one already. This is why it is sufficient for the context menu handler to simply strip it off.

The client behavior for this tag does two things.

1. If the link is clicked without the context menu, no action is taken. The already-existing ClientWindow is allowed to remain on the link, causing the correct ClientWindow to be carried forward.

2. If the link is clicked with the context menu (new tab or new window), the ClientWindow is removed before the browser issues the GET. This will cause a new ClientWindow to be created for the new tab (or window), this is the correct action in this case.

Comment by tandraschko [ 20/Dec/13 ]

@Ed
is it really possible to listen on "onclick" when the link will be openend in new tab via context menu?
I'm sure onclick won't be called.

Maybe we should never render the windowId to a link und just add via onclick.
We could store the windowId globally in a JS varable in in the listener, we could add it to the href.

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-1162] Dynamically created ClientBehaviors do not call addComponentResource Created: 07/Feb/13  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: kennardconsulting Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Both Mojarra and MyFaces 2.1.x implementations behave the same



 Description   
  • If I dynamically create UIComponents using the new Application.createComponent( context, componentType, rendererType ), I find they automatically add any dependent resources (JS/CSS) to the h:head. This is fantastic.
  • If I dynamically create ClientBehaviours using Application.createBehavior( id ), no dependent resources get added.

Am I supposed to add such resources manually? For example:

UIOutput js = new UIOutput();
js.setRendererType("javax.faces.resource.Script");
js.getAttributes().put("library", "mylibrary");
js.getAttributes().put("name", "bar.js");

FacesContext context = FacesContext.getCurrentInstance();
context.getViewRoot().addComponentResource(context, js, "head");

If so, how am I supposed to know what they are? For example, if I am dynamically adding an AjaxBehavior the exact name of the JavaScript file depends on which JSF implementation I am using.

Also logged as https://issues.apache.org/jira/browse/MYFACES-3610 (but got no response, so I'm trying it as a spec issue)



 Comments   
Comment by kennardconsulting [ 07/Feb/13 ]

The MyFaces team have indicated this may be a bug in the spec:

"the reason it does not work is because javax.faces.component.behavior.AjaxBehavior does not have @ResourceDependency attached"
https://issues.apache.org/jira/browse/MYFACES-3610

Could you please discuss?

Comment by kennardconsulting [ 08/Feb/13 ]

I checked javax.faces.component.behavior.AjaxBehaviour.java in the latest 2.2 snapshot...

https://maven.java.net/content/repositories/snapshots/javax/faces/javax.faces-api/2.2-SNAPSHOT/javax.faces-api-2.2-20130207.091549-141-sources.jar

...and it doesn't appear to be annotated there either?

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-1236] For Ajax File Uploads: Investigate the use of XMLHttpRequest2 (If available). Created: 31/Jul/13  Updated: 13/Aug/14

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

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

Attachments: Text File mojarra-trunk-xhr2-upload.patch    

 Description   

Investigate the use of XMLHttpRequest (Level2) for file uploads (if available) and fall back to iframe if it is not available.



 Comments   
Comment by kfyten [ 10/Sep/13 ]

Reminder that ICEsoft has submitted a patch for this, would be nice if the JIRA reflected this, etc.

Also note that MyFaces has preliminary support for this already, see https://issues.apache.org/jira/browse/MYFACES-2852.

Comment by rogerk [ 30/Sep/13 ]

Contribution From IceSoft

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-723] add partial parameter Created: 19/Jan/10  Updated: 01/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 723
Status Whiteboard:

size_small importance_large


 Description   

add attribute partialSubmit="true/false" to f:ajax and
parameter partialSubmit:'true/false' to jsf.ajax.request options

Only the components named in the "execute" parameter are processed in phase 2-4,
but the spec insists on submitting all elements included in a form. If
partialSubmit is set to true submission is reduced to the form params named in
execute. This is a performance feature that can boost speed on large pages.



 Comments   
Comment by ganeshpuri [ 19/Jan/10 ]

Set target milestone to 2.1

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 29/Jun/10 ]

status whiteboard

Comment by rogerk [ 29/Jun/10 ]

target milestone

Comment by ganeshpuri [ 30/Jun/10 ]

Former name: "partialSubmit", but "partial" is more compact.
Would be great to get this into JSF 2.1

Comment by rogerk [ 13/Sep/10 ]

unfortunately this will go into 2.2

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by tedgoddard [ 21/Apr/11 ]

This is a very good feature provided that there is also a "whitelist" of additional parameters that must be submitted with every Ajax post. Alternatively, a JavaScript callback could be registered to allow frameworks to add required parameters to the POST before submission.

Comment by Ed Burns [ 25/Apr/11 ]

Regarding the whitelist, we do have that already as documented in the JSDoc.

I strongly favor the callback option. We already have a function jsf.getViewState(formElement). We could specify that a user provided function is called before returning from getViewState() that takes the associative array and the function can modify the associative array however they like.

Comment by arjan tijms [ 13/Nov/11 ]

MyFaces seems to have implemented this and calls it Partial Page Submit (PPS). Werner Punz recently blogged about this great feature here: http://werpublogs.blogspot.com/2011/07/apache-myfaces-jsfjs-queue-control.html

Incidentally, JavaServer Faces 2.0 The Complete Reference already spoke about a "Partial Submit" (page 343 "... only the value of the userid field is submitted" and Figure 12-2, page 345).

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-682] Add support for XHR timeout Created: 02/Dec/09  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 682
Status Whiteboard:

size_large importance_large


 Description   

Add support for XHR timeout.

This is marked as a P1 spec defect - it was felt during the EG Ajax meeting that
this lack of support for timeout was a critical failure.

A request that is unexpectedly long running, or a network timeout, can
completely freeze the client. Hence, the P1 status.



 Comments   
Comment by ganeshpuri [ 21/Jan/10 ]

corrected target

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 28/Jun/10 ]

target 2.1_gf31_m5

Comment by rogerk [ 03/Sep/10 ]

starting

Comment by rogerk [ 03/Sep/10 ]

I am looking to introduce a "timeout" attribute (property) on the ajax.request
(and also f:ajax tag) where u can specify a time in milliseconds. For example:

onclick="jsf.ajax.request(this, event,

{execute: this.id, render: 'out1', timeout: '5000'}

);....

and also

f:ajax timeout="5000"...

Comment by rogerk [ 13/Sep/10 ]

target MS6

Comment by rogerk [ 20/Sep/10 ]

Out of time for this for 2.1.

Comment by werpu12 [ 06/Mar/12 ]

MyFaces has timeout already in with a custom parameter.
You cam pass a myfaces

{timeout:<value>}

in the options list.

The timeout should be an option like execute and render.

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-674] Allow ajax response short-circuit/override Created: 20/Nov/09  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 674
Status Whiteboard:

cat2 frame size_medium importance_medium


 Description   

Currently, JSF handles an ajax response, including the re-rendering of the
specified components, every time, even if onevent is specified. There are times
when the ajax response requires custom handling. For example, the HTML returned
after rerendering a large data table might need to be passed to a Javascript
widget so it can update its state in a widget-specific manner. There is
currently no way to do this.

I would like to see the ajax portion of the spec modified to allow client code
to override the response handling, thus assuming the full burden of updating the
client.



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

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-658] PartialViewContext interoperability Created: 02/Nov/09  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Attachments: Text File jsf-spec.patch    
Issuezilla Id: 658
Status Whiteboard:

cat1 frame size_large importance_medium


 Description   

Contract of PartialViewContext doesn't give enough freedom for JSF components libraries to override it
partially. Example: simple addition of "extension" element (or any other that RI's implementation doesn't
do, but component libraries may need) requires full re-implementation of PartialViewContext class, thus
making co-existence of different libraries almost impossible. If some AJAX-updated component outputs
"extension" element, then it appears inside "update" element causing malformed XML error on the client,
so this approach doesn't work.



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

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

2.0 rev a

Comment by Ed Burns [ 15/Mar/10 ]

frame

Comment by rogerk [ 14/May/10 ]

Just to be clear...
Are you proposing an API change on PartialViewContext?
Can you please provide a more concrete example and use case?

Comment by rogerk [ 14/May/10 ]

Ownership

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by rogerk [ 17/May/10 ]

Target 2.1

Comment by nick_belaevski [ 18/May/10 ]

More concrete example can be update/insertion/deletion of component part. Let's
take filterable data table component. When user types something in filter field,
live update of table content should be happening, but we aren't going to update
the whole table, because this will cause loss of user's input focus. So,
component assigns id="#

{clientId}:tbody" to <tbody> element with the intention
to update it later by special event.

Looking at the API of PartialViewContext, how would component be doing this?
There's processPartial(PhaseId phaseId) that does the complete processing and in
Mojarra it is implemented via visiting components tree using either
PartialVisitContext or FullVisitContext. So, if we add component clientId into
renderIds, implementation will call component's encodeAll(...) method wrapping
it into <update id="#{clientId}

">...</update> element. If we don't add component
clientId, then control won't be passed to component at all. If we call
startUpdate()/endUpdate() for our <tbody> from encodeAll(...), then <update>
elements are nested and XML is not correct, causing update to fail (this has
been already discussed in jsr-314 mailing list). The same problem with any
insert/delete/extension element. Solution: do complete re-write of
PartialViewContext, but this affects interoperability in a poor way.

Proposed API change: two methods that will allow users to override creation of
VisitContext & VisitCallback for the particular phase.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by rogerk [ 30/Jun/10 ]

target

Comment by rogerk [ 26/Aug/10 ]

Nick - I need to push this to 2.2 unless you can supply the spec changes.

Comment by nick_belaevski [ 26/Oct/10 ]

Created an attachment (id=318)
Proposed patch

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-638] Ajax Back Button Support Created: 24/Sep/09  Updated: 12/Aug/14

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

Type: New Feature Priority: Major
Reporter: driscoll Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-718 Allow PhaseListener instances to rece... Closed
blocks JAVASERVERFACES_SPEC_PUBLIC-542 autocomplete attribute missing on for... Open
Issuezilla Id: 638
Status Whiteboard:

cat2 frame size_large importance_large draft


 Description   

Many modern Ajax frameworks support back button actions.

JSF should as well.

This probably means both browser history manipulation and state restoration.
Could be pretty hard to do, but really important for being seen as a real Ajax
solution.



 Comments   
Comment by driscoll [ 08/Oct/09 ]

Also, see here for a newly proposed standard by Google:

http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

unscheduled

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 18/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

On 5 May 2010, at the JAX conference, this feature was requested, but in a slightly different guise. The
requestor wanted something like

<h:backButton ...> with an optional "number of views to go back" attribute.

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by werpu12 [ 06/Mar/12 ]

Ok Ajax back button support is tricky at best. I will investigate the following days into this issue. I know html5 will provide an official api and there are hacks which enable it via hashtags on the url. (the hashtag hacks also enable bookmarking for ajax)

I personally think in step 1 we should aim for the standardized html5 way of doing things and then aim lower with the hasthags which open another can of worms.

Comment by werpu12 [ 06/Mar/12 ]

https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history

is interesting information regarding this.

Comment by werpu12 [ 07/Mar/12 ]

Ok I was able to enable back button support with some html 5 see following link
https://gist.github.com/1993051

A detailed blog will follow. The problem i see is, that there are several approaches.
a) The simplest is to go for the pure html5 way. Then you have to snapshot the page and restore it upon a proper back button event.

b) The probably easiest one is, to enable the same by adding a html5 storage simulation and back button simulation to the page (and use hashtash for the back button simulation). This should be doable, or by simply storing the page shots in a javascript map.

c) The third one would be to enable something else via hashes in the url, that would need some server side patching additionally.

I will try to prototype approach b) tomorrow.

Comment by werpu12 [ 08/Mar/12 ]

https://gist.github.com/2000091 here is the same prototype for html4 browsers.

The problem i see here with both methods is, they are purely clientside, and rely on the state history to recover the correct state.
So they

a) need some kind of notification how deep the state history is to prevent states which result in an error.

b) it is still unclear on how to deal with embedded scripts in the page and onload handlers which rely on component initialisation.

We probably have to add a callback event which the component systems can hook in to reintialize their stuff, or we simply execute all embedded scripts even with the danger of getting sideffects.

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-307] Ajax Push (Reverse/Comet) Created: 18/Sep/07  Updated: 01/Aug/14

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

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

Operating System: All
Platform: Macintosh


Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-293 Ajax umbrella issue Closed
Issuezilla Id: 307
Status Whiteboard:

cat2 frame size_large importance_medium


 Description   

The specification must define the APIs/SPIs for pushing server side state
changes to the client (a.ka. comet, reverse ajax,...).
-------------------------------
Norbert Truchsess wrote:
> For real asynchronous comet-style communication there is an api to
> access the component-tree asynchronously on the server not in response
> to an HttpRequest (e.g. from a message-driven bean). Any change to the
> tree- and component state would be send to the client with the next
> response. In case of client-site statesaving the 'non httprequest based'
> call would be queued until the next HttpRequest comes in, then the state
> would be restored, the queued 'non-httprequests' would be processed in
> the same order they arrived and after that the regular processing of the
> HttpRequest would continue. In case of client-side statesaving where a
> communication-channel to the client is allready open (e.g. by means of a
> 'delayed' request that does not nessesarely contain the state) the
> delayed request would be released first, if it contains the state
> processing could continue as in the 'serverside statesaving' case. If no
> state is included in the request there would be an immediate response to
> the client containing a message that forces the client to send the state
> in a new request and processing may continue as described before.
-------------------------------
Roger Kitain wrote:
Sounds interesting. But how does this tie in with the inclusion of "Comet" in
the Servlet specification (JSR 315)? Does that simplify what you describe here?
-------------------------------
Norbert Truchsess wrote:
> The JSR 315 proposal talkes about non-blocking
> input/output, delayed request-handling, delayed response-close and
> Blocking/nonblocking notification (channel concept with the ability to
> subscribe to and get asynchronous events from that channel). The first 3
> items are just nessesary to do the client/server-part of the
> communication. If the last item (blocking/nonblocking notification) is
> describing a server-side feature (it sounds like the description of an
> existing feature in Grizzly), then it might/will help a lot to implement
> what I described above.
-------------------------------
Ted Goddard wrote:
> The approach taken by ICEfaces is essentially to allow the
> application to retain a reference to the FacesContext outside
> of the servlet request/response (we call it a PersistentFacesState).
> Then, the application can invoke render() on the associated
> component tree at any time, causing any page updates to be pushed
> to the client. Only one simultaneous render of the component tree
> is allowed, so client-initiated updates and server-initiated updates
> are applied coherently.
>
> We did not support client-side state saving with Ajax Push because
> a server-initiated update is only meaningful when the server has
> full knowledge of what it is updating ... but perhaps there is
> a use case where it can be applied.
-------------------------------
Norbert Truchsess wrote:
> Shure there's no gain in doing
> server-initiated updates without having access to the state on the
> serverside. But 'having' to retain the complete state on server (as it's
> done by ICEFaces results in quite limited scalability due to memory
> consumption. It would be beneficial to mark which parts of the
> component-tree-state are required during a server-initiated update so
> either only this part would be stored on the server or only this part
> would have to be 'requested' from the client before a server-initiated
> update could take place.

> My opinion here: let's target best of breed support for ajax in the
> framework itself. And that is support for 'real' comet-style push
> updates that can be used without any vendor-extensions 'out of the box'.
> We all know that the jcp is turning much slower than the techniques
> being used in the real world are evolving. At the time JSF 2.0 will be
> ready to ship the ajax-techniques being used out there world will be way
> more advanced then they are now and I bet support for
> comet-communication will be commodity in most 'non java based'
> web-application frameworks. If we don't have support for this 'build
> into the bases', jsf 2.0 will not be as attractive as it could be.
>
> Shure, not everyone needs it. Most enterprise-applications will do
> without it. So it should be optional to use - best would be to be able
> to switch in on/off at runtime for precisely that single page that e.g.
> contains a 'chat-component'. But wouldn't it be really cool, if you
> could use a chat-component by just placing it on the page and set
> 'communicationStyle="comet" in the view-tag? I'm more than convinced
> that this feature would rise the recognition of JSF as a modern
> technologie way more than most other things on our roadmap will do.
>
> This particular issue should not be priorized low just because a lack
> of resources in this EG. I hereby volunteer to write this chapter, the
> code and the tck even single-handet if no one else is willing to do
-------------------------------
Ted Goddard wrote:
> Ajax Push (also known as "comet", although that tends to
> refer to the Dojo implementation) is the main distinguishing
> feature of ICEfaces. ICEfaces is open source, so there is
> no barrier in principle to incorporating any desired
> parts of it into JSF 2.0.
>
> In terms of the technology, should it be part of JSF 2.0?
> - the server infrastructure really requires changes to the
> Servlet API (although asynchronous I/O is a goal of JSR-315)
-------------------------------
Norbert Truchsess wrote:
> I did invest quite some time to dig through ICEFaces
> implementation details, and from an architectural point of view I like
> it a lot. So if there would be no memory-contrains in reall-world
> scenarios I'd love to just take and transfer it into JSF 2.0. And in the
> reall world developers will not want to be constrained in using
> client-side widgets that do dom-manipulations on the client. (which also
> would be in conflict with our first assumtion 'Ajax.A01')
-------------------------------
Ted Goddard wrote:
> It's the JavaScript aspect that makes me hesitant to advocate
> Ajax Push for JSF 2.0 (since the Servlet changes are on the
> horizon), but I could certainly be persuaded otherwise.
-------------------------------
Roger Kitain wrote:
If would like to focus more on what's required on the server to facilitate this
feature, and ** not ** standardize lots of javascript (if that's possible).
-------------------------------
Norbert Truchsess wrote:
> 100% agree - Not
> that I think we could go without JS on the client here, but the the
> server-side requirenments are the prerequisite that has to be done first.



 Comments   
Comment by rogerk [ 18/Sep/07 ]

Set target milestone 2.0

Comment by Ed Burns [ 09/Sep/08 ]

Push to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by rogerk [ 20/Jan/10 ]

Target 2.1

Comment by Ed Burns [ 02/Mar/10 ]

status

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 22/Mar/10 ]

ajax

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by arjan tijms [ 09/May/13 ]

Now that WebSockets have been standardized in Java EE 7 (JSR 356), it might be the right time to reconsider standardizing push for JSF.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-879] Decoder that act as separate functionality Created: 29/Aug/10  Updated: 01/Aug/14

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

Type: Improvement Priority: Minor
Reporter: vladperl Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 879
Status Whiteboard:

size_large importance_large draft


 Description   

I suggest to introduce concept of decoders as functionality that works
independently from rendering functionality. JSF already has dedicated Renderer
class. So it makes sense to do the same thing for decoding functionality.
The first benefit from this approach would be possibility to send data from
client directly to decoder, skipping on the way to it necessity to use JSF
components and JSF life cycle. JSF developers will be able to create more
stateless JSF applications and use Javascript libraries in more flexible than
now manner.

The first usage of decoder would be the following kind of scenario:

client side:
jsf.ajax.post({data:

{'dataHolder.value': value1}

, render: 'input1');

server side:
if (isDataRequest(context.getExternalContext().getRequestHeaderMap()))

{ Decoder.handleDataRequest(context); context.responseComplete(); }

...
ValueExpression ve = getValueExpression(context, key);
ve.setValue(context.getELContext(), o.get(key));
...

Note: The first argument of the method "post" would be optional and called "url".
In case if developer need to customize handling of data from client we will use
this argument as way to identify decoder that will handle the data.

Complete signature of the Javascript method could be defined something like this:
jsf.ajax.post([url], [data], [handleAs], [render], [onSuccess(data)],
onError(data)]);



 Comments   
Comment by vladperl [ 29/Aug/10 ]

The following link seems could be used as supporting point:
http://forums.java.net/jive/thread.jspa?messageID=481227

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-873] Add pre and post ajax transaction function callbacks Created: 03/Aug/10  Updated: 01/Aug/14

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

Type: Bug Priority: Minor
Reporter: Ed Burns 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: 873
Status Whiteboard:

size_small importance_medium


 Description   

Use case: say the user wants to use some effect to fade in/out the content to be updated via Ajax. It
would be nice to have a way to install pre-request and post request callback functions. On the post
request, we need to have actually two functions. One when we have the response but have not yet done
the replacement, and another after we have done the replacement.



 Comments   
Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-865] Ajax inside a DataTable (getClientId append rowIndex) Created: 10/Jul/10  Updated: 01/Aug/14

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

Type: Bug Priority: Minor
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: 865
Status Whiteboard:

size_medium importance_large draft


 Description   

Comments from [jsr-314-open] Ajax inside a DataTable:

Cagatay Civici

I've faced with an issue in our app I'd like to share when trying to update the
datatable itself from a command element located inside a column. Case is to
select a row, execute logic and update the datatable. Basic code:

<h:dataTable id="cars" var="car" value="#

{tableBean.carsSmall}

">
<h:column>
<f:facet name="header">
Model
</f:facet>
<h:outputText value="#

{car.model}

" />
</h:column>

<h:column>
<f:facet name="header">
Action
</f:facet>
<h:commandButton value="Some Action"
actionListener="#

{tableBean.handleRowAction(car)}

">
<f:ajax render="cars" />
</h:commandButton>
</h:column>
</h:dataTable>

As datatable has a rowIndex >= 0 during rendering of commandButton f:ajax
defines the component id to render as cars:

{rowIndex}

where I should expect
"cars" only. This is due to UIData.getClientId implementation as UIData
adds rowIndex for unique row ids. This causes an issue with a nested f:ajax case.

Andy Schwartz

Ids specified by <f:ajax> are relative to containing component - in this case,
relative to the <h:commandButton>. This makes is easy to specify
execute/render ids for components within the same NamingContainer (which is by
far the most common case). In the case of iterating components like
<h:dataTable> or <ui:repeat>, this means that execute/render ids refer to
components within the same row.

There is a way out of this... You can specify an absolute id by prefixing the id
with ":". At that point the id starts from the root of the component tree and
you can specify any number of colon-separated segments to descend into each
naming container. (This matches the syntax used by findComponent().)

Of course, specifying absolute paths is at a minimum difficult, and in some
cases, just plain impossible to do (eg. when reusing content across multiple
pages). In Trinidad we use a double-colon prefix ("::") to reference up one
level in the NamingContainer hierarchy - similar to ".." in file system paths.
I suggested exposing this when we were working on the <f:ajax> spec, but this
topic got shelved until 2.1.

Dan has captured some of our thinking here:

http://seamframework.org/Documentation/JSF21#H-ReevaluateComponentReferencingMechanismP2

More here:

http://seamframework.org/Documentation/JSFEnhancementComponentReferencing

Oh, and... for the particular use case that you describe above, I think that it
is very important that the JSF implementations give some warning when a
referenced component is not found, at least when running in development project
stage. Not sure which implementation you are testing, but it might make sense
to log bugs against MyFaces/Mojarra if this is failing silently in development mode.

Martin Marinschek

> Ids specified by <f:ajax> are relative to containing component - in this
> case, relative to the <h:commandButton>. This makes is easy to specify
> execute/render ids for components within the same NamingContainer (which is
> by far the most common case). In the case of iterating components like
> <h:dataTable> or <ui:repeat>, this means that execute/render ids refer to
> components within the same row.

Yes, but what Cagatay totally correctly refers to is that the table is
certainly not in a row - how can the table be in a row of itself? This
is semantical nonsense.

We should never include the row-index in the client-id of the table
itself. For this, we need to revise the client-id generation
algorithm.

Without actually having tried it, I think that it is easy to do so, as
we have a UIComponentBase.getContainerClientId() to create the
client-id of the children - when this method is called, we append the
row-index, if getClientId() itself is called, we don´t. Does this
sound reasonable to you guys?

I think we can regard this as an implementation bug - Catagay, can you
open issues for Mojarra and MyFaces?

Leonardo Uribe

I just want to note a side effect of this change: getContainerClientId() was
introduced
in jsf 1.2, but code written in jsf 1.1 uses getClientId(). If we apply this change,
all libraries for jsf 1.2 needs to be updated. I think we can do this for jsf
2.0 but my
question is if we should apply this change on jsf 1.2 branch. Components written for
jsf 1.1 that extends from UIData will not work correctly with this change.

Martin Marinscheck

> Components
> written for
> jsf 1.1 that extends from UIData will not work correctly with this change.

ah, well - if they override the UIData functionality. Yes, you are
right. Well, not sure how we should handle this properly. Maybe we
should leave this for 2.0.

Andy Schwartz

Yes, but what Cagatay totally correctly refers to is that the table is
certainly not in a row - how can the table be in a row of itself? This
is semantical nonsense.

Ugh, yes, of course. For a moment there it slipped my mind that the UIData
component is indeed found as part of the relative id search. I was thinking
that only the stamped components would be considered valid execute/render
targets when a row index is set. But, since we spec'ed findComponent()
semantics for execute/render, the UIData would indeed be found, and, yes, we
should use the correct client id.

Leonardo Uribe

Added issue on myfaces:

MYFACES-2744 UIData.getClientId() should not append rowIndex, instead use
UIData.getContainerClientId()



 Comments   
Comment by rogerk [ 13/Jul/10 ]

triaged

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by cipriandobra [ 11/Aug/11 ]

A simple workaround is to place the dataTable inside a h:panelGroup and use its id.

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





[JAVASERVERFACES_SPEC_PUBLIC-861] Portlets + ajax API Created: 30/Jun/10  Updated: 29/Oct/14

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

Type: Bug Priority: Minor
Reporter: werpu12 Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Σ Remaining Estimate: 1 week, 3 days Remaining Estimate: 1 week, 3 days
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: 1 week, 3 days Original Estimate: 1 week, 3 days
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Blocks
blocks JAVASERVERFACES-3031 Support namespacing of parameters acc... Closed
blocks JAVASERVERFACES-3184 Support namespacing of parameters acc... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1069 Portlet incompatibilities with jsf.js Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-966 Make finding components involved by <... Sub-task Closed  
Issuezilla Id: 861
Status Whiteboard:

size_small importance_large


 Description   

Currently there is no clean standardized way to detect a portlet szenario for
the ajax apis and the attached scripts.
The main difference is as far as I know how the portlets are handled that we
have an identifier on the element identifying the portlets viewroot.

We need a publc api which allows to detect the portlet identifier so that
further processing is eased.
Also the apis have to be checked if they are portlet szenario save in their
specifications (which they probably are as soon as we have the portlet
identifier determination routine in).

Probably a public api like jsf.util.getViewRootId() suffices, which would under
normal szenarii return a "" and in a portlet scenario would return the root
identifier.



 Comments   
Comment by rogerk [ 30/Jun/10 ]

triage and target.

Comment by ganeshpuri [ 30/Jun/10 ]

Hi Werner,
Enhanced portlet support in JSF 2.1 would be extremely helpful. Do you have a
running JSF 2.0 + portlet scenario? Is the JSF 2.0 portlet bridge ready to run?
If we try to implement portlet features it would be helpful to be able to test
them
Best regards,
Ganesh

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by werpu12 [ 06/Jul/10 ]

I have not really a running scenario, I did some small prototying in this area a
while ago, after I checked what portlets do to a running applicaton, and it came
down to following issues:

a) First jsf.js or something else needs to allow a method to pass the viewRoot
identifier within a portlet szenario to the associated javascripts (I did an el
function to do that in my prototype, which then also was the root of a component
index, but that was already user space.

For convenience methods a functionality to get the client id of a component
within the current naiming container also is desireable (but not entirely
needed) that has been requested as far as I could see in another issue.

The biggest issue simply is on how to get the client identifier for your
viewRoot and the components so that you can adjust your jsf.ajax requests
accordingly and make subqueries on your portlet dom subtree.

The second issue which is really spec related is, how do you handle on protocol
level and on client side level, <updates> etc.. on head, body and viewroot in a
portlet scenario.

I am not sure if the portlet bridge really deals with that (I doubt it though),
because in case of render="@all" usually a update on ViewRoot is issued with
head and body replacement accordingly (which in case of the body replacement
definitely will destroy the portlet, in case of the head replacement not too
much will happen because only the javascrips will be evaluated anew)

But that might also be something which has to be covered within the portlet
bridge and an associated ppr response writer, which simply wont allow a viewroot
or body replacement.

Comment by rogerk [ 26/Aug/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by tedgoddard [ 21/Apr/11 ]

This JIRA appears to describe an API for obtaining the javax.faces.ViewState. This would be very useful in a number of cases:

  • obtaining the ViewState key as a stable value during page rendering would allow it to be directly written into rendered output removing the need for post processing of the response (for server-side state saving only)
  • the ViewState key could be guaranteed to be made available to each form, fixing some Ajax and full page refresh interoperability bugs
  • the ViewState key could be used to implement View "scope" objects without making use of the ViewMap directly, given that the ViewMap is not available until after the UIViewRoot has been restored (for instance, handling bean values affecting ui:include would be simplified)
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 Minor





[JAVASERVERFACES_SPEC_PUBLIC-1128] All form controls sent as request params when @none specified for execute. Created: 01/Aug/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: Minor
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A clarification is needed to state that no form controls should be sent if the 'execute' option is @none.
Currently, all form controls are encoded and sent regardless.



 Comments   
Comment by rogerk [ 01/Aug/12 ]

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

Comment by jasonzhang2002gmailcom [ 01/Aug/12 ]

In ajax call, all render parameters (@this, ids, @none) should be respected. The current implementation sends the whole form. All input controlls are evaluated(validated, and model are updated).

Comment by kithouna [ 07/Mar/13 ]

Isn't this perhaps a special case of JAVASERVERFACES_SPEC_PUBLIC-1098?

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-1122] RFE: make HtmlInputHidden a ClientBehaviorHolder so that it can be used as the target for AJAX change events in composite components Created: 12/Jul/12  Updated: 13/Aug/14

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

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


 Description   

I created a JSF 2 composite component that is rendered almost entirely using JavaScript. When the user makes a selection, it sets the value of a hidden input field. I am able to use an HtmlInputHidden as the cc:valueHolder of my composite component and it works as designed.

When I try to add an AJAX change listener, I get the following error:

<cc:clientBehavior name="change" event="change" targets="#

{cc.clientId}

:selectedRoom"/>

"Unable to attach behavior to non-ClientBehaviorHolder parent:javax.faces.component.html.HtmlInputHidden@150ef67"

When I change the h:inputHidden to an h:inputText, then the AJAX functionality works as designed. Please update JSF so that an inputHidden can be used in this way as well.



 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-930] f:ajax not working when response contains CDATA / ui:debug Created: 31/Jan/11  Updated: 12/Aug/14

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

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

Status Whiteboard:

size_medium importance_medium


 Description   

when calling an action-method that returns a string (viewId), f:ajax tries to
update the whole page with the new view.

This fails, when the source of the new view contains an xml-comment (CDATA) like
the one that gets automatically inserted through ui:debug.

when trying to update a page this way, an alert-box is shown, saying that update
failed.
Description
when calling an action-method that returns a string (viewId), f:ajax tries to update the whole page with the new view. This fails, when the source of the new view contains an xml-comment (CDATA) like the one that gets automatically inserted through ui:debug. when trying to update a page this way, an alert-box is shown, saying that update failed.
Show »

Sort Order: Ascending order - Click to sort in descending order



 Comments   
Comment by werpu12 [ 06/Mar/12 ]

I dont see this as a spec bug, the problem there probably is that the CDATA is not escaped correctly on the server by the partial response writer.
In MyFaces we do double buffering just for this issue, to avoid unescaped CDATAs in the ajax response.

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.





Support view actions that execute before tree is built w/ navigation support (JAVASERVERFACES_SPEC_PUBLIC-758)

[JAVASERVERFACES_SPEC_PUBLIC-975] Provide response headers in Event Data Payload Created: 15/Apr/11  Updated: 01/Aug/14

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

Type: Sub-task Priority: Minor
Reporter: Adrian Gygax Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_medium


 Description   

I need to access the response headers in a callback function as defined in section 14.4.1. I propose to extend TABLE 14-4 Event Data Payload like this:

responseHeaders | The response headers (XMLHttpRequest.getAllResponseHeaders()); Not present for "begin" event;

Alternatively, it might make sense to add the XMLHttpRequest (or equivalent) object itself available in the payload. This would allow for greater flexibility.

Reason:
In the system environment of one of our applications a non-standard HTTP proxy is setting response headers we have to evaluate and handle in Ajax requests. The callback mechansim is perfect for this and we made a POC with Mojarra 2.1.1-b03 that our needs are satisfied by just extending the event data payload as described.



 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 Minor





[JAVASERVERFACES_SPEC_PUBLIC-1016] Ability to add HTTP headers to an ajax request Created: 15/Jun/11  Updated: 12/Aug/14

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

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


 Description   

I would really like the ability to add HTTP headers to an ajax request through the jsf.ajax.request(...) call



 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-1302] Add JavaScript Hooks to fileUpload Created: 29/Aug/14  Updated: 29/Aug/14

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

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


 Description   

Allow to add a listener for "progress",
(and "complete", "error", "abort")

The idea is to be able to implement a progress bar without any need to write an own upload servlet.






[JAVASERVERFACES_SPEC_PUBLIC-1159] Add support for WAI-ARIA aria-live property for portions of the page updated via <f:ajax> Created: 28/Jan/13  Updated: 01/Aug/14

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

Type: New Feature Priority: Minor
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: accessibility

 Description   

Currently, JSF doesn't have any explicit support for WAI-ARIA (http://www.w3.org/WAI/intro/aria.php), except for the role attribute. <f:ajax> should be updated to use the aria-live attribute at the very least.

See EG thread here: http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2013-01/message/5



 Comments   
Comment by kito75 [ 01/Mar/13 ]

After looking at this in more detail, there are several attributes that one may need to apply to the element that's being updated by an Ajax:

  • role
  • aria-live
  • aria-busy
  • aria-atomic
  • aria-relevant

(See http://www.w3.org/TR/wai-aria-practices/#LiveRegions)

Only the page author (and possibly the component being re-rendered) know which attributes should be set, and what the values should be. Since the regions are denoted with these attributes up-front, perhaps there's not much for <f:ajax> to do after all, because the page author can either use pass-through attributes or HTML5-friendly markup to specify these attributes on the component that needs to be updated.

Comment by Ed Burns [ 27/Mar/13 ]

I like this idea, targeting for 2.3.

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





[JAVASERVERFACES_SPEC_PUBLIC-1224] HTML5 Form Validation Not Performed Before Ajax Submit Created: 30/Aug/13  Updated: 13/Aug/14

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

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


 Description   

Given an HTML5 form, with HTML% input types (such as email), form validation is not performed (for an invalid email entered) if the submit is over ajax.
This is because the current Ajax portion of the specification states specifically to collect form elements and pass on over ajax to server side.
We would need to specify (and implement) something to trigger form validation before even collecting elements for ajax submit.



 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-1138] Add a new attribute 'apply' to the execute/render family Created: 16/Oct/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: New Feature Priority: Minor
Reporter: SteGr Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mojarra 2.1.11



 Description   

Several times I've had the problem, that I want to process only some UIInputs of a form that requires to rerender this form after the AJAX request completed. The other UIInputs should keep their latest user-entered value and not that from the backing bean.

As far as I've seen it in the Mojarra 2.1.11 implementation, only those UIInputs will keep the value from the request, that are mentioned in the execute attribute of an AJAX component. I would highly recommend to either always apply the request values to the component tree without validation and updating the backing bean or to implement a new attribute like 'apply' which could be used to specify several IDs that should be additionally treated in the APPLY_REQUEST_VALUE phase to update the component tree (but nothing more).



 Comments   
Comment by SteGr [ 06/Mar/13 ]

Any progress or information on this 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-1146] Required fields can be skipped on form submission Created: 21/Nov/12  Updated: 13/Aug/14

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

Type: Improvement Priority: Minor
Reporter: frederickkaempfer Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File requiredValidation.tar.bz2    

 Description   

With JSF2's ajax features it is possible to specify a list of execute ids that should be considered on ajax form submission. With jsf.ajax.request the execute ids can be specified solely on the client side. This may cause problems when fields are set to required and the action method of - for example - a command button relies on them being filled out. Skipping them may lead to invalid data being saved in a database.

Similarly other fields can be skipped that would require a minimum length or other validations not allowing for empty values.

This is not limited to the ajax case, because every command component can be executed in ajax mode by using the jsf.ajax.request function on the client side.

JSF should provide a way to enforce the presence of fields on a partial request before executing a button's action method. This could be done by checking if the current ajax request is really triggered by one of the f:ajax tags attached to the command object by comparing the execute ids. To enable this behavior for example a "strictAjax" attribute could be added to h:commandButton / h:commandLink and similar components or a new tag f:strictAjax could be created.

A workaround is to verify the execute ids in the action method (FacesContext.getCurrentInstance().getPartialViewContext().getExecuteIds().contains("requiredForm").

I have attached a project that demonstrates the issue.



 Comments   
Comment by Ed Burns [ 21/Nov/12 ]

Before I invest the time to fully understand this, can you take a look at JAVASERVERFACES_SPEC_PUBLIC-1129 and see if it is related?

Ed

Comment by frederickkaempfer [ 21/Nov/12 ]

It is unrelated. This is a pure security/data integrity concern where JSF gives the client a bit too much control over the execution of the lifecycle.

Comment by kithouna [ 05/Mar/13 ]

This sounds a bit like the reverse of Rail's mass assignment vulnerability. Instead of blindly accepting data from input that was not rendered, this doesn't bark when data that should be there is not provided?

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-785] Ajax rendering lifecycle for components half broken + Solution. Created: 14/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: Minor
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: 785
Status Whiteboard:

size_medium importance_large


 Description   

The current state of affairs for component rendering is, that we render the
components in the ajax case by openening the <update> tag before handling the
control of the rendering to the component. Now this causes several problems.
First component authors are enforced into an artifical update part, which
prevents them from fully utilizing the control possibilities of the ajax API!
Secondly this causes problems in ajax cases where the component does not follow
the structure of one root element having the client id of the component as id.
Third this has caused problems in the past regarding javascript evaluation since
there was no clear way wether embedded scripts needed to be evaled or not (we
settled down on evaling them over both implementations)

Now here is a proposed change to remove that problem:
a) Define a marker interface AjaxAware or PPR Aware
b) The marker interface has to implement a method renderPPR
c) The rendering lifecycle now is extended to following first render the
component as done normally (the ppr aware components can react and render
placeholders), but the components which are render aware then need to be pushed
onto a stack which after the update phase is processed.
Once update is done the all components on the stack need to have renderPPR
called. Where they now have full control over the response xml.
Additionally if an open command from the response triggers a pprAware component
on as child of the original ppr control, the child must be pushed onto a stack.
Once the pprAware processing is done on the parent, the child stack has to be
processed etc...
Until all components are processed.

Advantages of this approach: It would allow full control of the ppr stack for
the component authors while being downward compatible to the existing approach.
Disadvantage you do not have full control over the entire rendering process if
you stack ppr aware components this might cause sidebehavior between ppr and non
ppr aware components if the ppr aware components are badly designed (a tradeoff
which I personally think can be lived with, since the burden is here on the
component author who gains significantly more control over the rendering
behavior of his components)



 Comments   
Comment by Ed Burns [ 19/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 [ 30/Jun/10 ]

triage - important

Comment by rogerk [ 27/Aug/10 ]

Additional info from
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=619
which is a duplicate of this issue:

It is not currently possible to call startEval from within component render -
because startUpdate has already been called, and they cannot nest.

From an email from Werner Punz:

I think the PPR ResponseWriter should have added behavior
> which means if you already are in an update tag (or generally open tag)
> opening another tag like the eval section should be stacked and then
> rendered after the open tag is closed.
>
> That way you can add eval sections for ppr cases in the long run and
> also can make use of more parts of the PPR Writer api. Currently the
> writer API as is, can only really be used for servlet cases not
> components due to already being in update.

Comment by rogerk [ 27/Aug/10 ]
      • Issue 619 has been marked as a duplicate of this issue. ***
Comment by rogerk [ 03/Sep/10 ]

Even though Werner has done most of the preparatory work on this issue, I still
have to move it to JSF
2.2.

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 Minor





[JAVASERVERFACES_SPEC_PUBLIC-742] f:param support for f:ajax Created: 09/Feb/10  Updated: 12/Aug/14

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

Type: Improvement Priority: Minor
Reporter: Ryan Lubke Assignee: Unassigned
Resolution: Unresolved Votes: 10
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-1532 f:viewParam with required="true" prob... Closed
Related
is related to JAVASERVERFACES-1532 f:viewParam with required="true" prob... Closed
Issuezilla Id: 742
Status Whiteboard:

cat2 javadoc size_medium importance_large


 Description   

Consider:
--------------------------------------

<f:view>
<f:metadata>
<f:viewParam id="country" name="country"
value="#

{welcome.country}

" required="true"
requiredMessage="The 'country' parameter is missing.
Invalid access for this page ...">
</f:viewParam>
</f:metadata>
</f:view>
<h:head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>Hello JSF 2! </title>
</h:head>
<h:body>

<h:messages id="messages" style="color: red;"
layout="table"/>

<h:form id="form">

<fieldset>
<p>
<h:outputLabel id="vip__Label" for="vip" value="Vip Lounge
Access">
</h:outputLabel>
<h:selectOneRadio id="vip" layout="pageDirection"
label="Vip Lounge Access"
required="true" immediate="true"
value="#

{welcome.vip}

">
<f:selectItem itemLabel="Yes" itemValue="true" />
<f:selectItem itemLabel="No" itemValue="false" />
<f:ajax execute="@this" render="@form :messages">
</f:ajax>
</h:selectOneRadio>

</p>
<p>
<h:outputLabel id="name__Label" for="name" value="Name" >
</h:outputLabel>

<h:inputText id="name" value="#

{welcome.name}

" label="Name">
<f:ajax execute="@this" render="name__Label :messages">
</f:ajax>
</h:inputText>
</p>
<div >
<h:commandButton value="Hello"
action="readback?faces-redirect=true&includeViewParams=true">
<f:param name="country" value="#

{param['country']}" />
</h:commandButton>
<h:commandButton value="Goodbye" immediate="true"
action="#{welcome.goodbye}" />
</div>
</fieldset>

</h:form>
</h:body>
...

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

Note the
<f:param name="country" value="#{param['country']}

" />
indented in <h:commandButton> to hold the country viewParam .

Note the f:viewParam 'country' is required for this view.

Note the f:ajax usage with the radio. When the radio is activated,
the country request parameter is not included and causes an error.

See https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1532 for further
details.



 Comments   
Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

javadoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/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.





[JAVASERVERFACES_SPEC_PUBLIC-737] Please define an expected behavior for an error in the AJAX callback Created: 03/Feb/10  Updated: 01/Aug/14

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

Type: Bug Priority: Minor
Reporter: Ryan Lubke 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: 737
Status Whiteboard:

cat1 frame size_medium importance_large draft


 Description   

I am working on the Apache MyFaces Trinidad AJAX code and trying to get it to
"play nicely" with JSF 2's AJAX. I am trying to resolve how Trinidad's client
validation code can fit in with the JSF 2 AJAX. Example use case:
<f:ajax>
<tr:inputText />
</f:ajax>
vs.
<tr:inputText autoSubmit="true"/>

In the latter case, Trinidad will perform client side validation before the AJAX
request is made, in the former, it will not because the request will bypass
Trinidad's JS and only use jsf.ajax.request to submit the form, which IMO, is
not desired.

As one possible idea, I am thinking to add a listener to JSF via
jsf.ajax.addOnEvent and potentially perform the client validation in the "begin"
event. In doing so, I would need a means to abort the request should validation
fail. Neither the specification nor the JS docs state the expected behavior of
the framework if a listener throws an error. In the JS code provided with the
Mojarra source I snee that throwing an Error would abort the request as it would
not be caught. I am not sure if this is an oversight or it is intentional.

For this bug I would like to see:
1) the specification or jsdoc updated to state how errors are handled within the
callback functions
2) a method recommended for JSF users that would allow client validation to hook
into the JSF ajax API in a way that allows the code to abort the request if
desired (via Error, return value from the callback, or something else) for a
future spec?

Thank you



 Comments   
Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 18/May/10 ]

move to p2

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 28/May/10 ]

I thought about just specifying "thow an Error()" but that's a bit clunky. I'd like something cleaner. Because
that's new behavior, move it to 2.1.

Comment by rogerk [ 18/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-738] No way to properly reference the ID of h:dataTable as an f:ajax render or execute target Created: 03/Feb/10  Updated: 12/Aug/14

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

Type: Bug Priority: Minor
Reporter: Ryan Lubke 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: 738
Status Whiteboard:

cat2 jsdoc size_medium importance_large


 Description   

Consider the case where an f:ajax reference is placed within a child component
of a h:dataTable component where the render target refers to the table itself.

When the client ID of the table is resolved, the ID includes the row index at
the time the behavior was rendered for the component wrapping the f:ajax tag.

There should be some way to obtain the raw client ID of a components like UIData
for this particular purpose.



 Comments   
Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

jsdoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 18/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 26/Aug/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-726] specifiy parameter 'queue' to define AJAX queue size Created: 19/Jan/10  Updated: 12/Aug/14

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

Type: Improvement Priority: Minor
Reporter: ganeshpuri 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: 726
Status Whiteboard:

size_small importance_large


 Description   

The 2.0 spec specifies an unlimited ajax queue, though for most usages a queue
size of 1 is appropriate.

This param makes the queue size configurable. Follow up requests would replace
prior request if the queue is full.

On jsr-314-open it was discussed whether queue size is a general config param,
but this doesn't hit the nail:

The desired queue size can differ with each use case, so it is meant to define
the number of queue elements one use case tolerates before throwing one out, so
f:ajax/jsf.ajax.request are the right place to put it.



 Comments   
Comment by ganeshpuri [ 19/Jan/10 ]

original discussion from jsr-314-open:

Actually the desired queue size can differ with
each use case, so this was meant to define the
number of queue elements this special request
tolerates before throwing one out, so f:ajax/
jsf.ajax.request could be the right place to put it.

Maybe "queue" would be nicer and more compact than "queuesize".

Best regards,
Ganesh

> 3. queuesize: The 2.0 spec specifies an unlimited ajax queue, though
> for most usages a queue size of 1 is appropriate. This param makes
> the queue size configurable. Follow up requests would replace prior
> request if the queue is full.
>
>
> I'm not sure this is appropriate for an f:ajax tag attribute. It sets a
application-wide flag for Ajax behaviors (correct?), and is not specific to the
Ajax request to which the f:ajax tag is assocated.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 30/Jun/10 ]

target

Comment by ganeshpuri [ 30/Jun/10 ]

clarification to get this into JSF 2.1:
To reduce complexity we have only 1 AJAX request queue in JSF 2.0 as opposed to
the concept of different queues for group of components.
This queue param is only meant to limit the size of this one queue and to throw
out the oldest queued request when a new one comes in.

Comment by rogerk [ 06/Jul/10 ]

triage

Comment by rogerk [ 13/Sep/10 ]

unfortunately this will have to go into 2.2

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-684] Be able to get a list of all client side event listeners Created: 02/Dec/09  Updated: 12/Aug/14

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

Type: Improvement Priority: Minor
Reporter: driscoll 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: 684
Status Whiteboard:

size_medium importance_large


 Description   

It should be possible to get a list of all registered client side event listeners.

Currently, there is no standard way.



 Comments   
Comment by ganeshpuri [ 21/Jan/10 ]

corrected target

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 26/Aug/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by werpu12 [ 06/Mar/12 ]

This is easy to implement. Should be for 2.2 definitely.

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-685] Add ability to cancel a client side listener Created: 02/Dec/09  Updated: 01/Aug/14

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

Type: Bug Priority: Minor
Reporter: driscoll 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: 685
Status Whiteboard:

size_large importance_large


 Description   

Sometimes, the page author would like to cancel a client side event listener.

currently, there is no way to do this - you would have to instead code the
listening function to stub out if some value were set, instead, or overwrite the
function with a noop. That's awkward.

Instead, it would be desired that the listener be removed from the list of
listeners that the JSF client library keeps.

One way to do this would be to have the addListener function return a token, and
have a separate, cancel(token) function which would remove the listener
represented by that token.



 Comments   
Comment by ganeshpuri [ 21/Jan/10 ]

corrected target

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 27/Aug/10 ]

For now re-target for 2.2.
If time permits may revisit for 2.1.

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by werpu12 [ 09/Mar/12 ]

The token approach is not needed, a client which registers a listener should always know the function. I guess a simple remove listener should be enough.
so that we have jsf.ajax.addListener and jsf.ajax.removeListener.
It is as simple as that and can be easily implemented.

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





[JAVASERVERFACES_SPEC_PUBLIC-689] Provide ajax function to get the number of requests on the queue Created: 03/Dec/09  Updated: 01/Aug/14

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

Type: Bug Priority: Minor
Reporter: driscoll 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: 689
Status Whiteboard:

size_small importance_large draft


 Description   

Customer request: Provide a jsf.ajax function to query the number of requests
that are currently waiting on the queue.

Easy to implement, and could conceivably be useful to a small class of users.



 Comments   
Comment by ganeshpuri [ 21/Jan/10 ]

corrected target

Comment by rogerk [ 18/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 26/Aug/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 Minor





[JAVASERVERFACES_SPEC_PUBLIC-681] Response XML should include a version # Created: 02/Dec/09  Updated: 01/Aug/14

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

Type: Bug Priority: Minor
Reporter: driscoll 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: 681
Status Whiteboard:

size_small importance_large


 Description   

The response xml should include a version number... An attribute? In the
doctype? Both places? Regardless, this was an oversight.



 Comments   
Comment by ganeshpuri [ 21/Jan/10 ]

corrected target

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 26/Aug/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 Minor





[JAVASERVERFACES_SPEC_PUBLIC-679] Chained response actions should all be run, even if one fails Created: 02/Dec/09  Updated: 01/Aug/14

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

Type: Bug Priority: Minor
Reporter: driscoll 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: 679
Status Whiteboard:

size_medium importance_large


 Description   

When an Ajax response is received with more than one action, all of them should
be run, even if one of them fails.

This will require a spec clarification.

However - what happens to the client event model in this case?

If we have three actions, and the second fails, we should probably generate the
error event. But what if all three fail? Or only the first two? The user
would be responsible for doing error handling - but they wouldn't know which
succeeded, and which failed. Generating more than one error event may be the
way to go here, I'll have to think about it further.

This would be more clearly handled with a new event type: see spec JAVASERVERFACES_SPEC_PUBLIC-678 for
more.



 Comments   
Comment by ganeshpuri [ 21/Jan/10 ]

corrected target

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-678] Add new client event type - between complete and success Created: 02/Dec/09  Updated: 12/Aug/14

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

Type: Improvement Priority: Minor
Reporter: driscoll Assignee: Unassigned
Resolution: Unresolved Votes: 8
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File jsf-spec.patch    
Issuezilla Id: 678
Status Whiteboard:

size_medium important_large


 Description   

There is a desire to have a new client event - coming between complete, and
success. While success is the event thrown when all the incoming commands are
successfully executed, it would be useful to have an event after each incoming
command is executed.

There would of course need to be additional information in the data payload of
this event: id effected, presumably, as well as the name of command executed
(update, eval, etc.) Maybe more? TBD.



 Comments   
Comment by ganeshpuri [ 21/Jan/10 ]

corrected target

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 30/Jun/10 ]
      • Issue 734 has been marked as a duplicate of this issue. ***
Comment by rogerk [ 30/Jun/10 ]

I'm adding verbage from other spec issue that will benefit from this:

Some kind of notification for AJAX-updated DOM elements is necessary to let
components being updated by AJAX to free memory. Details of the problem are
described in this thread at RichFaces forum:
http://community.jboss.org/thread/5742?tstart=0 .

Setting target (schedule) as well.

Comment by werpu [ 26/Aug/10 ]

Having sunk tremendous time recently into fixing client side ie gc issues on
MyFaces I can feel the pain of the component authors myself here.

From my personal experience we need two events here one for startProcessing...
with the command details, so that any pre cleanup work can be performed (saving
old dom nodes for further cleaning up etc...)

and a postProcessing event which then allows the cleanup. So I would add a
startCommand and endCommand event here with further details about the command
being passed down.

Comment by rogerk [ 27/Aug/10 ]

For now re-target for 2.2.
If time permits may revisit for 2.1.

Comment by nick_belaevski [ 26/Oct/10 ]

Created an attachment (id=317)
Proposed patch

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-655] Shared stack API for nested wrapping Behaviors Created: 22/Oct/09  Updated: 01/Aug/14

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

Type: Improvement Priority: Minor
Reporter: nick_belaevski 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: 655
Status Whiteboard:

cat2 javadoc frame size_medium importance_medium


 Description   

Currently, in Mojarra 2.0.0, there's no public API that tags/tag handlers from different component libraries can use in order to handle nested wrapping behaviors
properly. This can cause issues with nested behaviors provided by different vendors.
Example of use-case:

<f:ajax event="action">
<h:commandLink ... />

<rich:ajax event="action">
<h:commandLink ... />
</rich:ajax>
</f:ajax>

More closer behavior (rich:ajax) should be applied to the second command link, but rich:ajax and f:ajax have no common place to share information on their nesting.
There's com.sun.faces.component.behavior.AjaxBehaviors class in JSF 2.0 RI, however it's not portable (MyFaces is likely to use another name for this) and also it can
work only with instances of AjaxBehavior.



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

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

javadoc frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 30/Jun/10 ]

target

Comment by rogerk [ 26/Aug/10 ]

Nick - you are welcome to submit spec changes to get this into 2.1.

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-637] No way to determine xml entity escaping in Partial Responses Created: 24/Sep/09  Updated: 01/Aug/14

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

Type: Bug Priority: Minor
Reporter: driscoll 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: 637
Status Whiteboard:

cat2 frame size_large importance_large


 Description   

There is currently no way for the implementation to determine whether something
written to an partial request is intended to be escaped or not.

The usual way, in 1.2, was whether it was wrapped in a CDATA tag.

But all partial response text is wrapped in a CDATA tag.

This must be addressed for the next release - I've cobbled together something
that will work for 2.0, but it's going to be very fragile, and will break in
ways that are hard to diagnose for the enduser, as well as anyone extending JSF.



 Comments   
Comment by driscoll [ 24/Sep/09 ]

See Mojarra See Mojarra bug 1315
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1315

For a description of what went wrong because of this, as well as the
changebundle I needed to apply as a workaround.
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1315

For a description of what went wrong because of this, as well as the
changebundle I needed to apply as a workaround.

Comment by driscoll [ 28/Sep/09 ]

Also see Mojarra Also see Mojarra bug 1339.

One way to fix this (I think) would be for the PartialResponseWriter to actually
implement the entirety of the ResponseWriter contract..

One way to fix this (I think) would be for the PartialResponseWriter to actually
implement the entirety of the ResponseWriter contract.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 26/Aug/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 Minor





[JAVASERVERFACES_SPEC_PUBLIC-628] "always render" javascript API Created: 14/Sep/09  Updated: 12/Aug/14

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

Type: Bug Priority: Minor
Reporter: driscoll 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: 628
Status Whiteboard:

size_small importance_large


 Description   

RichFaces has the notion of autoupdate - a list of "always render" id's, that
are rendered for every ajax request.

A quick, naive implementation could be as simple as:

void jsf.ajax.addAlwaysRender(String id)

and then every jsf.ajax.request would have the "id" appended to the render list.

This would be trivial to implement.

The use case for this is actually a special case for component authors - while a
page author can manually add id's to the render list, component authors can't.



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

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by rogerk [ 18/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 22/Jun/10 ]

2.1

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by rogerk [ 29/Jun/10 ]

Correct Subcomponent

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 26/Aug/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Hanspeter Duennenberger [ 05/Jan/14 ]

Hi,

my 2 cents to this idea:

Why would that always id's have to be part of the jsf ajax api? Ids of components to always update could be managed server side only. Beside, sometimes it is also handy to execute a component with every request (aka always).

We implemented it in csJSF as a separate tag that can be placed on a page or template and is used like this:

<x:always execute="space separated id list" render="space separated id list" />

The mixin of the always to execute/render ids was done in a PartialViewContextWrapper - if this becomes JSF standard then mixin would be in PartialViewContext itself.

Best regards
Hanspeter

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-621] Allow cancellation of an unsent ajax request Created: 21/Aug/09  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: Minor
Reporter: driscoll 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: 621
Status Whiteboard:

cat2 javadoc size_small importance_medium


 Description   

If you have a situation where you are spamming the ajax queue with requests from
user input, it would be nice if there was a way to not saturate the queue.

One suggestion, request aggregation, raises all kinds of ordering issues.

But a simpler solution would be to simply return a token from jsf.ajax.request,
and then allow a cancel operation using that token. The cancel would only go
into effect if the request was yet unsent.

So,

var token = jsf.ajax.request(blah blah);
(find out that you want to cancel the request, possibly because a new request
superceds it)
var canceled = jsf.ajax.cancel(token);
if (canceled) {
alert("you canceled the request");
} else {
alert("didn't catch it in time, request went through");
}



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

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

javadoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 29/Jun/10 ]

target milestone

Comment by rogerk [ 27/Aug/10 ]

For now re-target for 2.2.
If time permits may revisit for 2.1.

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-571] Add an extension mechanism to the javascript event payload Created: 10/Jun/09  Updated: 01/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 571
Status Whiteboard:

cat2 frame jsdoc size_medium importance_large draft


 Description   

During the specification process, we stripped out the ability to extend the
javascript event payload.

This is a problem, as any changes to that payload would then be incompatible
with the spec, and prevent further expansions of that payload in future specs.

One simple proposal would be to allow implementations to simply prefix the name
of any property they add with "x".



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

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 18/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 [ 26/Aug/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 Minor





[JAVASERVERFACES_SPEC_PUBLIC-575] f:ajax Skip update model option Created: 22/Jun/09  Updated: 01/Aug/14

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

Type: Improvement Priority: Minor
Reporter: Ryan Lubke 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: 575
Status Whiteboard:

cat2 frame size_medium importance_large


 Description   

Hi all,

I was chatting with Alex Smirnov this week, and he pointed out that an essential
feature needed for Ajax validation is missing from the Ajax support in JSF 2.0.

When you are doing Ajax validation, you need an option to not update the backing
beans (in other words, skip the update model phase), so that *if the value is
valid*, then aren't saved to the model. I think this is sufficiently important
enough to go into the JSF maintenance release. The RichFaces syntax is like:

<f:ajax updateModel="false" />

BTW, Ed, any updates on the MR?

Pete



 Comments   
Comment by Ryan Lubke [ 22/Jun/09 ]

Re-open https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1161 when
this is being addressed by the specification.

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 20/Jan/10 ]
      • Issue 574 has been marked as a duplicate of this issue. ***
Comment by rogerk [ 24/Feb/10 ]

Target 2.0 Rev A

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by rogerk [ 28/Jun/10 ]

2.1_gf31_m5

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 [ 24/Jan/14 ]

Hello Cagatay,

Is JAVASERVERFACES_SPEC_PUBLIC-575 [1] solved by the cancel button work
we did in JSF 2.2? I think it might be.

Ed

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





[JAVASERVERFACES_SPEC_PUBLIC-556] Ajax Head Body Replacement Created: 04/May/09  Updated: 12/Aug/14

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

Type: Bug Priority: Minor
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


Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1069 Portlet incompatibilities with jsf.js Closed
Issuezilla Id: 556
Status Whiteboard:

cat2 frame size_medium importance_large draft


 Description   

w/r/t https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=552

Hello

I want to comment on the update section of the jsr 314.

It says with the latest proposal for changes:

javax.faces.ViewRoot:

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

</update>

Update the entire DOM as follows:

  • Extract the CDATA content and trim the <html> and </html> from the CDATA
    content if it is present.

<<<<<<< (remove the following lines)

  • If the CDATA content contains a <head> element, and the document has a
    <head> section, extract the contents of the <head> element from the <update>
    element's CDATA content and replace the document's <head> section with this

contents.

  • If the CDATA content contains a <body> element, and the document has a
    <body> section, extract the contents of the <body> element from the <update>
    element's CDATA content and replace the document's <body> section with this

contents.

======= (add the following lines)

  • If the CDATA content contains a <head> element, and the document has a
    <head> section, replace the document's <head> section with the <head> section

contained within the CDATA content.

  • If the CDATA content contains a <body> element, and the document has a
    <body> section, replace the document's <body> section with the <body> section

contained within the CDATA content.

This still is problematic. The issue is following:
You still have to parse the head and body sections out of the CDATA block, you
cannot assume valid xml within comes in!
Now lets have a look at the details:
The RI tries to solve this and fails in cases where body or head sections occur
in embedded scripts or in xml/html comments!
You have to implement a full parser to resolve this, which we have started!
But I personally think it would be preferrable to resolve this entirely on
server level, since we have the entire information
on the server available anyway (at least in almost all cases) and not try to
offload this onto the client and have javascripts resolve the parsing!

I would propose following change:

<update id="javax.faces.ViewRoot">
<![CDATA[...]]>
or
<head>
<![CDATA[...]]>
</head>
<body>

<![CDATA[...]]>
</body>
</update>

With the simple CDATA block containing the entire stripped html markup
(preferrable withouth the html tags, but if they have to be included
no comments before or after are allowed, the html content
must be prestripped)

and head and body containing the markup for the head section and the body section
(including the tags)

both either head and body can occur without the other!

No parsing should occur on client level, or minimal parsing, if CDATA is served
the entire html content is replaced
for body and head only the body and head sections are replaced as they occur!

As I said before, we have started to work on the parser as needed by the current
spec, but I am not sure if it would not
be better to leave the splitting of the html and head sections to the server
part and do not offload it to the client.
For performance reasons it definitely would not impact the server significantly
while it would introduce another
load on the client which can be avoided!

an implementation this way would look like following

<update id="javax.faces.ViewRoot">
<![CDATA[
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
</head>

<body>
body section
</body>
</html>
]]>

</update>

in this case the entire html block is replaced via the data delivered by CDATA

<update id="javax.faces.ViewRoot">

<head>
<![CDATA[
<head> <title></title> </head>
]]>
</head>
<body>

<![CDATA[
<body>
body section
</body>
]]>
</body>
</update>

or

<update id="javax.faces.ViewRoot">
<body>

<![CDATA[
<body>
body section

</body>
]]>
</body>
</update>

In none of these cases any significant parsing on the client side must occur!

Kind Regards

Werner Punz



 Comments   
Comment by rogerk [ 04/May/09 ]

target

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by Ed Burns [ 04/Mar/10 ]

I talked to Werner at JSFDays about this.

Comment by Ed Burns [ 17/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 28/Jun/10 ]

2.1_gf31_m5

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 Ed Burns [ 04/Aug/14 ]

Leave unchanged.





[JAVASERVERFACES_SPEC_PUBLIC-552] Ajax Response Handling - View State / Body Created: 30/Apr/09  Updated: 12/Aug/14

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

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

Operating System: All
Platform: Macintosh


Attachments: Text File jsf.js.diffs.txt    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1069 Portlet incompatibilities with jsf.js Closed
Issuezilla Id: 552
Status Whiteboard:

cat2 frame jsdoc size_medium importance_large


 Description   

This request actually came in from the myfaces folks who are implemented a jsf 2
ajax solution (following spec):

When developing the AJAX part of MyFaces 2.0 we encountered 2 locations within
the jsdoc part of the spec we'd propose for enhancement.

The first is about the hidden inputs for view state: The jsdocs for
jsf.ajax.response imply that each hidden input receives the id
"javax.faces.ViewState" which would result in multiple hidden inputs with this
id in a multi form document. This is how Mojarra is currently working things
out, but other implementations should get a chance to use a w3c conformant
approach - the hidden inputs don't need ids at all, but only
name=javax.faces.ViewState. A comment on this was already posted by Werner Punz.

The second is about replacing the body section of a document if the server sends
the id javax.faces.ViewRoot: The jsdocs for jsf.ajax.response say that the impl
should >>extract the contents of the <body> element from the <update> element's
CDATA content and replace the document's <body> section with this contents<<.
According to this the attributes of the body element wouldn't be replaced with
the new attributes, which probably isn't the intended behaviour. Preserving the
attributes can either be achieved by copying them or by using
contextualRagen/adjacentHTML instead of innerHTML.

Here is a proposal for changing the jsdocs for jsf.ajax.response to enable both
enhancements mentioned above - please correct the jsdoc for <static>
jsf.ajax.response(request, context)
like this:

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

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

Update the entire DOM as follows:

  • Extract the CDATA content and trim the <html> and </html> from the CDATA
    content if it is present.

<<<<<<< (remove the following lines)

  • If the CDATA content contains a <head> element, and the document has a
    <head> section, extract the contents of the <head> element from the <update>
    element's CDATA content and replace the document's <head> section with this
    contents.
  • If the CDATA content contains a <body> element, and the document has a
    <body> section, extract the contents of the <body> element from the <update>
    element's CDATA content and replace the document's <body> section with this
    contents.

======= (add the following lines)

  • If the CDATA content contains a <head> element, and the document has a
    <head> section, replace the document's <head> section with the <head> section
    contained within the CDATA content.
  • If the CDATA content contains a <body> element, and the document has a
    <body> section, replace the document's <body> section with the <body> section
    contained within the CDATA content.

>>>>>>>

  • If the CDATA content does not contain a <body> element, replace the
    document's <body> section with the CDATA contents.

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

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

Include this state in the document as follows:

  • Extract this <update> element's CDATA contents from the response.

<<<<<< (remove the following lines)

  • If the document contains an element with the identifier
    javax.faces.ViewState replace its contents with the CDATA
    contents.
  • For each <form> element in the document:
    o If the <form> element contains an <input> element with
    the identifier javax.faces.ViewState, replace the
    <input> element contents with the <update> element's
    CDATA contents.
    o If the <form> element does not contain an element with the
    identifier javax.faces.ViewState, create an <input>
    element of the type hidden, with the identifier
    javax.faces.ViewState, set its contents to the <update>
    element's CDATA contents, and add the <input> element as
    a child to the <form> element.

======= (add the following lines)

  • Set the value of all elements within the document with the name
    javax.faces.ViewState to the CDATA contents
  • Perform the following optionally, implementations my omit this to enhance
    performance, as it enforces a search within the DOM tree. For each <form>
    element in the document:
    o If the <form> element does not contain an element with the
    name javax.faces.ViewState, create an <input> element of
    the type hidden, with the name javax.faces.ViewState,
    set its value to the <update> element's CDATA contents,
    and add the <input> element as a child to the <form>
    element.

>>>>>>>

Best Regards,
Ganesh Jung



 Comments   
Comment by rogerk [ 01/May/09 ]

Created an attachment (id=224)
changes

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

jsdoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by rogerk [ 28/Jun/10 ]

2.1_gf31_m5

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 Ed Burns [ 04/Aug/14 ]

Leave priority unchanged.





[JAVASERVERFACES_SPEC_PUBLIC-503] Ajax application cannot determine that a ViewExpired Exception has occured. Created: 06/Nov/08  Updated: 01/Aug/14

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

Type: Bug Priority: Minor
Reporter: driscoll 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: 503
Status Whiteboard:

cat2 jsdoc size_medium importance_large


 Description   

Currently, an Ajax application cannot determine when the view has expired.

It just looks like any other 500 error.

This will probably require a specification addition to allow this.

The workaround is to have some sort of keepalive Ajax request on the page in a
timer, but that can be quite expensive for certain classes of applications, as
well as not working for every conceivable use case.



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

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by lincolnbaxter [ 26/Jan/10 ]

Categorized as part of Rev 2.0 A prep

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

jsdoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 26/Aug/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 Minor





[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-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-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-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-329] Add new single HTML radio button component that isn't bound to a list Created: 05/Feb/08  Updated: 25/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: rdelaplante Assignee: Manfred Riem
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-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-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.





HTML5 Support (JAVASERVERFACES_SPEC_PUBLIC-1090)

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

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

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

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

 Description   

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

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

button
fieldset
input
keygen
label
meter
object
output
progress
select
textarea

Proper provision must be made for these in JSF 2.2



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

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

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





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

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

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

N/A



 Description   

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

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

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

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



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

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





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

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

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

All


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

 Description   

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

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



 Comments   
Comment by paul_dijou [ 29/Oct/12 ]

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

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

Comment by paul_dijou [ 13/Nov/12 ]

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 13/Aug/14 ]

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

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

Just outputs:

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

This clearly is not what is intended.





[JAVASERVERFACES_SPEC_PUBLIC-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-961] Limited layout of SelectManyCheckbox and SelectOneRadio Created: 01/Apr/11  Updated: 01/Aug/14

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

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

Attachments: JPEG File screenshot-1.jpg    
Status Whiteboard:

size_large importance_small


 Description   

<h:selectManyCheckbox> and <h:selectOneRadio> are very limited regarding the output and layout of the individual items. For example is not possible to output any further description for the items. Furthermore rendering tables for layout is quite old fashioned.

Sine these are base components and used very often they should be improved to support user defined output like MyFaces tomahawk eliminating the need for additional component libraries.



 Comments   
Comment by Ranger [ 28/Apr/11 ]

It would be very nice to be able to make design like this with use of <h:selectManyCheckbox>

<h:selectManyCheckbox> use of tables make it impossible.

I think this issue should have a higher priority.

I have meet limiteations of the <h:selectManyCheckbox> and <h:selectOneRadio> several times.

And made work around using <h:inputHidden>, <input type="checkbox"> and JavaScript to transfer values from checkboxes and radio buttons to the <h:inputHidden> to use them in JSF.

Comment by rdelaplante [ 11/Jul/14 ]

+1

I wonder if this is related to JAVASERVERFACES_SPEC_PUBLIC-329

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-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-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-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-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:

http://showcase.omnifaces.org/components/messages

"Control iteration markup fully by the new var attribute which sets the current FacesMessage in the request scope and disables the default table/list rendering."

<o:messages var="message">
<li class="#

{fn:toLowerCase(message.severity)}

">#

{message.summary}

</li>
</o:messages>



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1291] RFE: Ability for h:messages to display a single custom message whenever the component has received any faces message. Created: 11/Jul/14  Updated: 01/Aug/14

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

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

Attachments: PNG File single message.png    

 Description   

In OmniFaces you can use h:messages to display a single message at the top of the screen such as "There are validation errors. Please fix them.", and then display component specific messages beside the components. They have added a "for" attribute to h:messages that points to the form component, and a "message" for the message to display. I will attach a screenshot.

http://showcase.omnifaces.org/components/messages

I've had customers ask me to do this very thing in our production applications.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1271] Simplify overriding a component's renderer Created: 27/Mar/14  Updated: 01/Aug/14

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

Type: New Feature 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


 Description   

A component in JSF can be customized by overriding its renderer and creating a new tag for it, e.g as demonstrated here: https://weblogs.java.net/blog/mriem/archive/2013/11/07/jsf-tip-34-override-jsf-renderer-and-create-new-tag-it

This however requires a small but tedious amount of XML. As an analogy to the createTag attribute of FacesComponent a similar attribute on @FacesRenderer could simplify this task and provide a greater ease of use. E.g. the XML in the above referenced example could be replaced by the following:

@FacesRenderer(forComponentType="javax.faces.HtmlOutputText" tagName="myOutputText")
public class MyTextRenderer extends Renderer {
    // ...
}

Overriding the render of a component and keeping its existing tag requires roughly the same amount of XML, but less straightforward. It requires the user to find out what the render-kit-id, component-family and renderer-type is of the component for which they want to override. This is demonstrated e.g. here: https://weblogs.java.net/blog/mriem/archive/2013/11/05/jsf-tip-32-override-jsf-renderer

It would be great if this could be simplified to just this:

@FacesRenderer(forComponentType="javax.faces.HtmlOutputText")
public class MyTextRenderer extends Renderer {
    // ...
}

As a user often primarily knows a component by its namespace and tag name, it might be worthwhile to let the user alternatively reference the component via this kind of naming. E.g.

@FacesRenderer(forComponentTag="http://java.sun.com/jsf/html:outputText")
public class MyTextRenderer extends Renderer {
    // ...
}


 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-1376] Missing StateHolder in Behaviour API for usage in dataTable and alike Created: 22/May/15  Updated: 22/May/15

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

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


 Description   

Recently I came across the fact that the Behaviour API is not using the StateHolder.

This means that EL Expressions in attributes of custom ClientBehaviours are executed during the buildView step and not during the 'rendering' (getScript() ) of the clientBehaviour.

As a consequence, the EL can't reference a var defined in the dataTable.






[JAVASERVERFACES_SPEC_PUBLIC-1341] Default value for viewParam Created: 10/Dec/14  Updated: 19/Jun/15

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

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


 Description   

What about allowing the definition of a default value for a view-parameter?

Example

Defining number of displayed items (pagination feature) as a view-parameter but still keeping default value within xhtml and not java bean.

Following example is a very clean approach provinding a default value.

<f:viewParam name="pageSize" value="#{bean.pageSize}" default="10"/>
<p:dataTable rows="#{bean.pageSize}"/>

Currently there are two workarounds which have no clean separation between markup and java code:

Workaround 1

Passing the default value to bean.

<f:viewParam name="pageSize" value="#{bean.pageSize}"/>
<f:event type="preRenderView" listener="#{bean.initPreRenderView(10)"/>
<p:dataTable rows="#{bean.pageSize}"/>
private int pageSize;

public void initPreRenderView(int pageSize)
{
	if (this.pageSize == 0)
		this.pageSize == pageSize;
}

Workaround 2

Hardcoding the default value in bean. But markup should be responsible and not bean.

<f:viewParam name="pageSize" value="#{bean.pageSize}"/>
<p:dataTable rows="#{bean.pageSize}"/>
private int pageSize = 10; 


 Comments   
Comment by djmj [ 19/Jun/15 ]

When using `ìncludeViewParams=true` on a link or command or using programmatically `getBookmarkableURL` the view parameters who's value equal their default value can be ignored.

This solves the problem of irrelevant parameters appended to link components. This behavior can be optional or optionally be deactivated using a param like `index.xhtml?appendDefaultValues=true`

A `<h:link>` with `<f:param name="pageSize" value="10">` can be ignored in the final URL.





[JAVASERVERFACES_SPEC_PUBLIC-1363] Add cols attribute to selectManyCheckbox Created: 12/Feb/15  Updated: 12/Feb/15

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

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


 Description   

If a bigger list of checkboxes should be displayed, either the page gets very wide or height. It would be useful to display two or more columns of checkboxes. Frankly, the layout should be restricted to a spcified number of columns and automatically gets extended in height.

add attribute "cols" of type int to selectManyCheckBox. If omitted, assume a default of 1.

If layout="pagedirection" (vertical) than cols > 2 creates multiple cols of checkboxes. The checkboxes will be created from left to right until a count of "cols" is reached. Then the layout continues with the next line. Thus, the total height is apx. n/cols.

If layout="linedirection", than cols is ignored. Optionally, an attribute lines is used for this layout. Now n/lines cols will be created.



 Comments   
Comment by muellermi [ 12/Feb/15 ]

example:

layout="pagedirection"
[] item1
[] item2
[] item3
[] item4
[] item5

layout="pagedirection" cols="2"
[] item1 [] item2
[] item3 [] item4
[] item5

ayout="linedirection" lines="2"
[] item1 [] item2 [] item3
[] item4 [] item5





[JAVASERVERFACES_SPEC_PUBLIC-1184] Support using JSON for component updates instead of XML Created: 22/Apr/13  Updated: 13/Aug/14

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

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


 Description   

One of the primary complaints about JSF is speed. We have paid a lot
of attention to optimizing server-side state over the past few years,
but we can also optimize the processing on the client. When a
component is updated via Ajax, currently we render the entire
component, even if only one property has changed. It would be much
more efficient if we sent only the changed properties via JSON and let
the client-side representation of the component update itself
accordingly. I have implemented a limited version of this for one of
my clients, and Ajax updates are noticeably faster. Updating the spec
to support this would not be a major change (because components would
opt-in to this feature), but it would have a dramatic affect on
client-side Ajax updates.

Initial EG thread: https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/105

I will post a more formal proposal later.



 Comments   
Comment by arjan tijms [ 11/May/13 ]

This sounds very useful! The title may not tell the whole story though; it's thus not just about JSON vs XML, but also about doing delta updates instead of full updates, right?

Comment by kito75 [ 13/May/13 ]

Arjun, you're exactly 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.





[JAVASERVERFACES_SPEC_PUBLIC-1206] required attribute is not enforced for inputFile Created: 08/Jul/13  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: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.0, Firefox


Issue Links:
Related
is related to JAVASERVERFACES-2923 required attribute is not enforced fo... Closed
Tags: file, file_upload, require

 Description   

When I select file at browser or not, I always have a part at server side. If no file is selected, the Part.size is zero.



 Comments   
Comment by Manfred Riem [ 08/Jul/13 ]

Can you please supply an example that reproduces the problem?

Comment by jasonzhang2002gmailcom [ 09/Jul/13 ]

This can be reproduced easily.


@RequestScoped
@Named
public class Test
{
	Part file;
	String str;
	public String getStr()
	{
		return str;
	}
	public void setStr(String str)
	{
		this.str = str;
	}
	public Part getFile()
	{
		return file;
	}
	public void setFile(Part file)
	{
		this.file = file;
	}
	public String save()
	{
		System.out.println("save is called");
		return null;
	}
}
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	xmlns:h="http://xmlns.jcp.org/jsf/html"
	xmlns:f="http://xmlns.jcp.org/jsf/core"
	xmlns:c="http://xmlns.jcp.org/jsp/jstl/core"
	xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
	
<h:body>
	<h:messages>
	</h:messages>
	<h:form enctype="multipart/form-data">
		<h:inputFile value="#{test.file}" id="file" required="true"></h:inputFile>
		<h:inputText value="#{test.str}" id="string" required="true"></h:inputText>
		<h:commandButton value="submit" action="#{test.save}">
		</h:commandButton>
	</h:form>
</h:body>
</html>
Comment by Ed Burns [ 09/Jul/13 ]

Manfred and I investigated this and determined that UIInput.isEmpty() doesn't correctly handle this case when there is a Part that is empty.

UIInput.isEmpty() was added in support of JAVASERVERFACES_SPEC_PUBLIC-426.

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-1211] UIOutput.resetValue() and UIInput.resetValue() produce unwanted state that is equal to the default values of the property accessor methods Created: 30/Jul/13  Updated: 01/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: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle-1211.txt    
Issue Links:
Dependency
depends on JAVASERVERFACES-2965 UIData performance and state saving i... Closed

 Description   

UIOutput/UIInput resetState() call set methods that cause StateHelper to add state that actually is the same as the default values that would be returned by the respective get-methods.

Proposed state neutral solution is be to remove the state from StateHelper using getStatehelper().remove(PropertyKey.xxx).



 Comments   
Comment by Hanspeter Duennenberger [ 30/Jul/13 ]

if resetValue() would remove the state UIData could make use of UIInput.resetValue() while restoring descendant state iterating the rows.

Comment by Hanspeter Duennenberger [ 30/Jul/13 ]

Added changebundle containing the proposed changes.

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-1197] Support multiple attribute on h:inputFile Created: 10/Jun/13  U