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

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

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

Operating System: All
Platform: Macintosh


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

size_small importance_small


 Description   

Following problem

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

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

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

Now the specification says:

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

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

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

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

However if you do following:

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

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

Mojarra also fails.

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

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

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



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

Agree for inclusion in 2.0 Rev a

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 27/May/10 ]

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

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by werpu12 [ 12/Jul/10 ]

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

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by frederickkaempfer [ 21/Sep/11 ]

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

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

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

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

Comment by frederickkaempfer [ 22/Sep/11 ]

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

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

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

Comment by werpu12 [ 22/Sep/11 ]

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

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

Comment by rogerk [ 22/Sep/11 ]

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

Comment by frederickkaempfer [ 22/Sep/11 ]

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

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

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

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

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

Comment by rogerk [ 22/Sep/11 ]

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

Comment by werpu12 [ 22/Sep/11 ]

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

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

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

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

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

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

Comment by frederickkaempfer [ 23/Sep/11 ]

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

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

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

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

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

Comment by frederickkaempfer [ 23/Sep/11 ]

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

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

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

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

Comment by werpu12 [ 23/Sep/11 ]

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

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

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

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

Comment by frederickkaempfer [ 23/Sep/11 ]

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

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

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

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

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

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

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

Comment by Ed Burns [ 23/Sep/11 ]

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

Comment by codylerum [ 02/Nov/11 ]

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

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

Comment by mdirkse [ 06/Dec/11 ]

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

Comment by werpu12 [ 06/Dec/11 ]

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

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

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

Comment by rogerk [ 06/Dec/11 ]

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

Comment by mdirkse [ 06/Dec/11 ]

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

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

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

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

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

Comment by frederickkaempfer [ 02/Jan/12 ]

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

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

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

Comment by codylerum [ 15/Feb/12 ]

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

Comment by frederickkaempfer [ 22/Feb/12 ]

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

Comment by Ed Burns [ 03/May/12 ]

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

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

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

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

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

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

Comment by tedgoddard [ 07/May/12 ]

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

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

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

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

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

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

Comment by boogi [ 31/May/12 ]

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

Comment by javaone9 [ 02/Nov/12 ]

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

Comment by frederickkaempfer [ 18/Apr/13 ]

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

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

Thanks a lot.

Comment by kfyten [ 25/Apr/13 ]

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

Thx.

Comment by rogerk [ 26/Apr/13 ]

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

Comment by balusc [ 08/May/13 ]

This is really unfortunate.

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

Comment by frederickkaempfer [ 08/May/13 ]

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

Comment by arjan tijms [ 08/May/13 ]

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

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

Comment by codylerum [ 08/May/13 ]

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

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

Comment by swathireddy12 [ 22/Aug/13 ]

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

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

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

Comment by werpu [ 22/Aug/13 ]

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

Comment by balusc [ 13/Jan/14 ]

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

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by donvip [ 25/May/16 ]

Is this issue going to be fixed in JSF 2.3?

Comment by arjan tijms [ 25/May/16 ]

Is this issue going to be fixed in JSF 2.3?

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

Comment by balusc [ 30/May/16 ]

I'm currently looking at this.

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

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

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

OmniFaces FixViewState by the way follows #2.

Comment by werpu [ 30/May/16 ]

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

Comment by balusc [ 30/May/16 ]

Completely agree that. I updated the previous comment.

Comment by balusc [ 02/Jun/16 ]

Still no feedback from portlet guys.

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

Comment by werpu [ 02/Jun/16 ]

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

Comment by werpu [ 02/Jun/16 ]

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

Comment by balusc [ 02/Jun/16 ]

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

Comment by donvip [ 02/Jun/16 ]

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

Comment by Neil Griffin [ 03/Jun/16 ]

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

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

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

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

The following HTML would be rendered to the response:

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

If you consider the following XHR response:

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

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

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

Comment by balusc [ 06/Jun/16 ]

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

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

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

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

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

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

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

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

The <UNIQUE_PER_VIEW_NUMBER> has no value in the API

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

Comment by Neil Griffin [ 06/Jun/16 ]

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

Comment by balusc [ 07/Jun/16 ]

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

Comment by Neil Griffin [ 10/Jun/16 ]

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

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

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

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

Comment by Neil Griffin [ 11/Jun/16 ]

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

Comment by balusc [ 11/Jun/16 ]

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

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

Comment by Neil Griffin [ 13/Jun/16 ]

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

Comment by Neil Griffin [ 14/Jun/16 ]

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

Comment by balusc [ 17/Jun/16 ]

I see, will keep that in mind.

Comment by balusc [ 20/Jun/16 ]

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

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

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

ViewHandler#writeState(FacesContext)

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

PartialViewContext#processPartial(PhaseId)

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

PartialResponseWriter#startDocument()

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

jsf.ajax.request

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

jsf.ajax.response

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

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

Comment by Neil Griffin [ 27/Jun/16 ]

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

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

Would you instead consider:

Util.java
return viewRoot.getContainerClientId(context);

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

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

Comment by balusc [ 28/Jun/16 ]

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

Comment by Neil Griffin [ 28/Jun/16 ]

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

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

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

For example, see HtmlBasicRenderer.java

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

A good example is ResponseStateManagerImpl.java.

Comment by balusc [ 04/Jul/16 ]

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

Comment by balusc [ 04/Jul/16 ]

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

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

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

Comment by balusc [ 06/Jul/16 ]

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

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

Comment by lu4242 [ 20/Jul/16 ]

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

Comment by balusc [ 20/Jul/16 ]

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

Comment by balusc [ 21/Jul/16 ]

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

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

Comment by werpu [ 21/Jul/16 ]

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

Comment by werpu [ 21/Jul/16 ]

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

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

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

Comment by balusc [ 21/Jul/16 ]

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

Comment by Neil Griffin [ 22/Jul/16 ]

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

Comment by Neil Griffin [ 23/Jul/16 ]

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

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

Comment by balusc [ 23/Jul/16 ]

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

Comment by Neil Griffin [ 24/Jul/16 ]

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

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

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

but it needs to be:

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

Thank you, Neil

Comment by balusc [ 24/Jul/16 ]

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

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

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

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

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

Comment by balusc [ 24/Jul/16 ]

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

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

Comment by Neil Griffin [ 25/Jul/16 ]

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

Comment by Neil Griffin [ 25/Jul/16 ]

Do you think specifying in API is necessary?

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

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

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

Comment by balusc [ 25/Jul/16 ]

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

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

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

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

Comment by balusc [ 27/Jul/16 ]

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

Comment by balusc [ 25/Sep/16 ]

@Neil: coming back to the deviating view root namespacing in portlets, one way to bridge this difference is to bring back the context param com.sun.faces.namespaceParameters which will then be used to drop the separator character from view root client ID. This way existing applications using older portlet impls will remain unaffected while upgrading JSF. In the meanwhile, you could have all time to fix it at portlet side to align with standard JSF namespacing rules.

Comment by Neil Griffin [ 18/Oct/16 ]

@balusc: Thank you for the suggestion regarding com.sun.faces.namespaceParameters. I will spend some time working on the bridge and if bringing back that context param becomes necessary, then I will let you know.

Regarding the problem with non-namespaced clientIds, in the Pluto+Tomcat bundle I have a demo JSF portlet that contains the following XHTML:

<h:form id="a">
	<h:outputText value="This is 'form a'" />
	<h:outputLabel for="foo" value="Enter a new value for foo:" />
	<h:inputText id="foo" value="#{testBean.foo}" />
	<h:commandButton action="#{testBean.action}" value="click me to execute 'form a' and 'form b' but re-render 'form b'">
		<f:ajax execute="a b" render="b" />
	</h:commandButton>
</h:form>
<h:form id="b">
	<h:outputText value="This is 'form b'" />
	<h:outputLabel for="foo" value="Enter a new value for foo:" />
	<h:inputText id="foo" value="#{testBean.foo}" />
	<h:commandLink value="click me to execute 'form a' and 'form b'  but re-render 'form a'"
		onclick="jsf.ajax.request(this,event,{execute:'a b',render:'a'}); return false;"/>
</h:form>

The h:commandButton in form a renders to:

<input id="Pluto_com_liferay_faces_issue_790_portlet_1_682392512_0_:a:j_idt9" type="submit" name="Pluto_com_liferay_faces_issue_790_portlet_1_682392512_0_:a:j_idt9" value="click me to execute 'form a' and 'form b' but re-render 'form b'" onclick="mojarra.ab(this,event,'action','Pluto_com_liferay_faces_issue_790_portlet_1_682392512_0_:a b','b');return false">

The h:commandLink in form b renders to:

<a href="#" onclick="jsf.util.chain(this,event,'jsf.ajax.request(this,event,{execute:\'a b\',render:\'a\'}); return false;','mojarra.jsfcljs(document.getElementById(\'Pluto_com_liferay_faces_issue_790_portlet_1_682392512_0_:b\'),{\'Pluto_com_liferay_faces_issue_790_portlet_1_682392512_0_:b:j_idt18\':\'Pluto_com_liferay_faces_issue_790_portlet_1_682392512_0_:b:j_idt18\'},\'\')');return false">click me to execute 'form a' and 'form b'  but re-render 'form a'</a>
Comment by balusc [ 28/Nov/16 ]
<f:ajax execute="a b" render="b" />

This is not valid in first place. It should have been

<f:ajax execute="a :b" render=":b" />

Relative client ids are interpreted relative to current naming container. The b would be interpreted as a:b.

Comment by Neil Griffin [ 30/Nov/16 ]

@balusc: You are exactly right. I must have copied the jsf.js.ajax(...) code from the original description in this ticket and duplicated the problem in the <f:ajax/> example as well. I fixed the portlet example according to your recommendations and the preliminary results look good. I will continue testing and report back with final results. Thanks for your help – Neil.

Comment by Neil Griffin [ 01/Dec/16 ]

@balusc: In my testing I found that the "replacing the entire viewroot" use-case mentioned by frederickkaempfer on 23-Sep-2011 still seems to be unsupported in both webapps and portlets.

Given the following two views:

view1.xhtml
<?xml version="1.0"?>
<f:view
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:f="http://xmlns.jcp.org/jsf/core"
    xmlns:h="http://xmlns.jcp.org/jsf/html">
    <h:head />
    <h:body>
        <h:form>
            <h:commandButton action="/views/view2.xhtml" value="Navigate to view2">
                <f:ajax execute="@form" render="@all" />
            </h:commandButton>
        </h:form>
    </h:body>
</f:view>
view2.xhtml
<f:view
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:f="http://xmlns.jcp.org/jsf/core"
    xmlns:h="http://xmlns.jcp.org/jsf/html">
    <h:head />
    <h:body>
        <h:panelGroup>
            <h:form id="view2Form">
                <h:commandButton action="/views/view1.xhtml" value="Navigate to view1" />
            </h:form>
        </h:panelGroup>
    </h:body>
</f:view>

When clicking on the "Navigate to view2" button, the javax.faces.ViewState hidden field is lost. This is because the submitting form on view1 went away, as detected by lines 1248-1252 of jsf.js:

jsf.js
if (!stateForm || !stateForm.elements) {
    // if the form went away for some reason, or it lacks elements 
    // we're going to just return silently.
    return;
}
Comment by stiemannkj1 [ 02/Dec/16 ]

Neil Griffin, balusc,
I'm going to work on a fix for this @all/Ajax navigation problem in jsf.js (hopefully one which will be compatible with webapps and portlets).

- Kyle

Comment by stiemannkj1 [ 02/Dec/16 ]

Here's my current work on this if anyone wants to look it over (unfortunately the diff is kinda ugly): https://github.com/stiemannkj1/mojarra/commit/e8f7f196636c17fe87e870030626d38a49be23fc. I still need to test this in both webapps and portlets for ViewState and ClientWindow. I also need to make the style more consistent (tabs vs. spaces) etc. So it's not quite ready yet, but hopefully it will be by Monday.

Branch on github: https://github.com/stiemannkj1/mojarra/tree/fix-render-%40all-JSF-SPEC-790

Comment by stiemannkj1 [ 02/Dec/16 ]

Here's a better diff with the tabs converted to spaces: https://github.com/stiemannkj1/mojarra/commit/1a8993c9f6ae2857c0310f6600dc0ea82ed56c26. Hopefully that's clearer.

Comment by stiemannkj1 [ 05/Dec/16 ]

I think I've finished the code, but I'm having some trouble with HtmlUnit tests. Gonna work more on this tomorrow, but you can see the diff here: https://github.com/javaserverfaces/mojarra/compare/26174a11...stiemannkj1:fix-render-@all-JSF-SPEC-790?expand=1

Comment by balusc [ 06/Dec/16 ]

I will look at it once I'm finished with 1396.

Comment by stiemannkj1 [ 06/Dec/16 ]

Okay I think this is complete now, but I have some failing tests which I still need to check on:

servlet30/ajax
servlet30/systest
javaee8/importConstants
javaee7/multiFieldValidation

Not sure if those failures are my fault yet. vsingleton, can you check if those failures occur in master? If not, I will debug them tomorrow.

See changes here: https://github.com/stiemannkj1/mojarra/tree/fix-render-@all-JSF-SPEC-790

Note that I had to tell JUnit to @ignore my tests since they require HtmlUnit 2.24-SNAPSHOT due to https://sourceforge.net/p/htmlunit/bugs/1815/ (the tests do pass with 2.24-SNAPSHOT though).





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

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

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

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

size_small importance_medium


 Description   

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

The features of this ResourceHandler include the following:

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

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

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

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

{resource['...']}

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

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



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

add duplicate links.

Comment by Jakob Korherr [ 13/Jun/11 ]

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

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

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

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

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

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

Comment by Hanspeter Duennenberger [ 26/Aug/11 ]

Hi Jakob,

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

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

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

regards
Hanspeter

Comment by lu4242 [ 29/Aug/11 ]

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

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

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

Comment by Jakob Korherr [ 04/Sep/11 ]

Hi Hanspeter,

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

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

Regards,
Jakob

Comment by Hanspeter Duennenberger [ 03/Oct/11 ]

Hi Jakob,

any progress here?

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

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

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

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

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

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

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

Cheers
Hanspeter

Comment by Jakob Korherr [ 06/Oct/11 ]

Hi Hanspeter,

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

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

Regards,
Jakob

Comment by Hanspeter Duennenberger [ 09/Feb/12 ]

Hi all.

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

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

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

The reference to this resource could be:

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

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

Regards
Hanspeter

Comment by Jakob Korherr [ 14/Feb/12 ]

Hi hanspeter,

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

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

Regards,
Jakob

Comment by Ed Burns [ 27/Feb/12 ]

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

Comment by Jakob Korherr [ 29/Feb/12 ]

Hi Ed,

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

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

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

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

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

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

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

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

Here, style.css still gets loaded via:

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

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

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

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

If you have any further questions, please ask!

Regards,
Jakob

Comment by Jakob Korherr [ 29/Feb/12 ]

Added sample_broken.zip

Comment by Ed Burns [ 29/Feb/12 ]

Thanks for demonstrating to me exactly how this is broken.

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

Comment by Ed Burns [ 29/Feb/12 ]

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

META-INF/relative-resources.xml

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

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

Comment by Ed Burns [ 29/Feb/12 ]

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

css_master.css:

@import url(#

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

);

Is it performance?

Comment by Jakob Korherr [ 29/Feb/12 ]

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

There are many reasons:

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

{resource[]}

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

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

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

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

Comment by Ed Burns [ 20/Mar/12 ]

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

Here's a clue, from RelativeResourceHandler#132.

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

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

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

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

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





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

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

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

Tags: state, validation

 Description   

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

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

The following reproduces this:

viewparam.xhtml
<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:f="http://java.sun.com/jsf/core"
>

    <f:metadata>
        <f:viewParam id="id" name="id" value="#{viewParamBean.id}"/>
    </f:metadata>

    <h:body>

        <h:messages />

        #{viewParamBean.id} <br/>

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

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

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

    private long id;    
    private String text;

    public void actionMethod() {

    }

    public long getId() {
        return id;
    }

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

    public String getText() {
        return text;
    }

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

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

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

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

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

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

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

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



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





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

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

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

Operating System: All
Platform: All


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

cat2 frame size_medium importance_large cat3 draft


 Description   

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

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

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



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

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

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

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

lifecycle

Comment by Ed Burns [ 07/May/10 ]

Transaction token has been requested many times over the years.

Comment by kito75 [ 08/May/10 ]

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

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

xsrf

Security related, target for GlassFish 3.1 M3

Comment by Ed Burns [ 30/Jun/10 ]

cat3

Comment by rogerk [ 01/Jul/10 ]

Hey Kito -

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

-roger

Comment by rogerk [ 01/Jul/10 ]

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

Comment by Ed Burns [ 01/Jul/10 ]

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

Comment by rogerk [ 01/Jul/10 ]

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

Comment by kito75 [ 14/Jul/10 ]

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

Comment by kito75 [ 14/Jul/10 ]

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

Comment by kito75 [ 14/Jul/10 ]

I have attached two samples:

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

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

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

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

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

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

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

Comment by kito75 [ 14/Jul/10 ]

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

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

Comment by rogerk [ 22/Jul/10 ]

re-target

Comment by rogerk [ 23/Jul/10 ]

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

Comment by rogerk [ 13/Aug/10 ]

target

Comment by rogerk [ 13/Aug/10 ]

Starting

Comment by rogerk [ 27/Aug/10 ]

reset priority

Comment by rogerk [ 13/Sep/10 ]

target 2.2

Comment by joshbrookes [ 18/May/11 ]

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by codylerum [ 23/Mar/15 ]

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

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

Comment by Manfred Riem [ 06/Aug/15 ]

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

Comment by kito75 [ 10/Aug/15 ]

Sure, I can.

Comment by gerhard_petracek [ 11/Sep/15 ]

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





[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: 11
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-1024] Allow parents of forms as render targets of ajax requests Created: 11/Jul/11  Updated: 12/Aug/14

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

Type: Bug Priority: Minor
Reporter: frederickkaempfer Assignee: Unassigned
Resolution: Unresolved Votes: 10
Labels: None
Remaining Estimate: 5 hours
Time Spent: Not Specified
Original Estimate: 5 hours

Tags: ajax, facelets, javascript

 Description   

Currently it is not possible to use parents of forms as render targets in <f:ajax/> or jsf.ajax.request. If an element containing one or more forms is specified in the render attribute, these forms' ViewState is not updated during the Ajax request. In my opinion it is not clear from the JSDocs, if parents of forms are allowed as render targets or not. Mojarra currently does not create an error in that case, however the jsf.ajax.request method does not create a ViewState field for descendant forms either.

Judging from the JSDoc the request method's execute parameter is not limited to forms and children of forms, it just takes a list of arbitrary client ids. It's also possible to specify '@all' for the whole view thus most likely a parent of multiple forms, which works as expected.

However the JSDoc for jsf.ajax.response states the following for ViewState updates:

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. Locate and update the javax.faces.ViewState value for all forms specified in the render target list.

This will clearly not work if only forms that are contained in the render target list directly are considered, because the list could also contain parents of forms.

For more information see the corresponding Mojarra bug report:

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



 Comments   
Comment by frederickkaempfer [ 12/Jul/11 ]

"Judging from the JSDoc the request method's execute parameter "

This was meant to be the render parameter.

Comment by frederickkaempfer [ 12/Sep/11 ]

This issue is related to (or even included in) http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790. Since this is obviously a spec bug and a fix is quite simple (updating all forms instead of only a subset defined by the render attribute on an ajax request, see Ed Burns' comment on 790) it would definitely be worth considering for 2.2.

Comment by arjan tijms [ 08/Jan/12 ]

Simple test case from duplicate issue JAVASERVERFACES-1788:

<h:panelGroup layout="block" id="group">
    <h:form>
        <h:commandLink value="Link A">
            <f:ajax />
        </h:commandLink>
    </h:form>
</h:panelGroup>

<h:form>
    <h:commandLink value="Link B">
        <f:ajax render=":group" />
    </h:commandLink>
</h:form>
  1. Press Link A - view state is submitted
  2. Press Link B, then Link A - view state is not submitted anymore
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 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-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-217] Add a styleClass attribute to h:column Created: 12/Oct/06  Updated: 04/Nov/16

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

Type: Improvement Priority: Major
Reporter: dmlloyd 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: All


Attachments: Text File issue217.patch     Text File JAVASERVERFACES_SPEC_PUBLIC-217.patch    
Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-627 Inconsistent column styles handling w... Open
Issuezilla Id: 217
Status Whiteboard:

cat2 renderkitdoc size_small importance_small


 Description   

Add a styleClass attribute to h:column and relegate the columnClasses attribute
from h:dataTable to a purpose similar to what rowClasses does: cycle through
each item in the list repeatedly (the use case being the ability to apply
alternating styles, like differently-colored even and odd columns, without
requiring knowledge of the number of columns).

There should be nothing in the <h:dataTable> attribute list that is dependant
upon the actual number of columns appearing inside of the table. All
information related to specific columns should be associated with each column's
corresponding <h:column> entity. Indeed, this is already the case with the sole
exception of the columnClasses attribute.

This is related to: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=426



 Comments   
Comment by dmlloyd [ 13/Oct/06 ]

Incidentally, adding a styleClass attribute to the <h:column> tag can be done
without breaking backwards compatibility. Changing the behavior of
columnClasses will be somewhat more difficult. You may want to create a new
attribute called columnCycleClasses or something - or maybe not, given that the
1.2 JSF implementation implemented the columnClasses attribute incorrectly
(until just now), and said implementation happens to concur with my proposed
behavior.

Comment by dmlloyd [ 26/Jan/07 ]

Created an attachment (id=110)
Implement a styleClass property on <h:column>

Comment by Ed Burns [ 15/Oct/08 ]

I've asked the Mojarra team if they think this is ok to do.

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 mojavelinux [ 01/Mar/10 ]

Update milestone and component.

Comment by mojavelinux [ 01/Mar/10 ]

In addition to the styleClass attribute, the style attribute should be added as
well. Assigning a style to a column is something that simply cannot be done with
the current <h:dataTable>/<h:column> component pair.

Comment by Ed Burns [ 03/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

renderkit

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Mark Struberg [ 12/May/11 ]

hi!

just like to push this up since I already came across this issue a few times.
Today a colleague of mine had this again: he looked at <h:column> where he found the footerClass and headerClass attributes, but no styleClass for h:column. The columnClasses attribute in <h:dataTable> is not a full replacement since you cannot do data based css assignment.

This is e.g needed if you have a accounting balance and a cash column with debit and credit values, and like to show all credits in green and debits in red.
Of course you can do this with <span> but it is not really intuitive why there is no styleClass on the <td> at all.

Comment by i_oss [ 12/May/11 ]

+1 (also for Dan's style-attribute)

Additionally i'd like to propose that we also add a possibility to add a styleClass/style per row, that can depend on the current var-value, instead of having to calculate the classes for all rows upfront. (There is also no way to add a style-attribute per row). Unfortunately rowClasses is already taken. While rowStyleClass would be perfect I think it is to close to rowClasses.
so:

<h:dataTable var="item" value="..." 
        rowStyle="#{item.important ? 'font-weight: bold' : ''}"
        rowStyleClass='trilternate#{component.rowIndex%3}'>

Not so important: Introduce varstatus as for ui:repeat / c:forEach, even if you can calculate index/last/first/etc. from #

{component}

, I think most template authors will not know that + it gets ugly.

Eventually!!! document, that 'global'-column-styling should be done with <f:facet name="colgroups">, if possible (less to render).

Comment by codylerum [ 03/Oct/13 ]

+1

Defining classes one per column in order on the datatable via columnClasses is far to brittle. RichFaces has provided this for years in their rich:column via styleClass http://docs.jboss.org/richfaces/4.3.X/4.3.0.Final/vdldoc/

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major, because of higher vote count

Comment by codylerum [ 13/Feb/16 ]

With Richfaces sun-setting in June 2016 it would be very nice to pick this feature up in 2.3

This is really the only feature that keeps me from using the native JSF datatable

Comment by codylerum [ 23/Jun/16 ]

I've gone ahead and implemented styleClass on column and rowClass on datatable.

This aligns with now Richfaces named the properties.

https://github.com/codylerum/mojarra/tree/JAVASERVERFACES_SPEC_PUBLIC-217

I'm going to need some review and pointers to know if I've updated the docs correctly.





Deprecate "targets" concept (JAVASERVERFACES_SPEC_PUBLIC-901)

[JAVASERVERFACES_SPEC_PUBLIC-755] passing through of actionListener, action,.. not possible between composite components Created: 27/Feb/10  Updated: 01/Aug/14

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

Type: Sub-task Priority: Major
Reporter: Jakob Korherr 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 755-cc-attribute-full-solution.patch     Text File 755-cc-attribute-Nested-No-EL.patch     Text File 755-cc-attribute-with-EL.patch     Zip Archive 755-reproducer.zip     Zip Archive composite-component-targets-test-4.zip     File composite-component-targets-test.war     File composite-component-targets-test.war     Zip Archive composite-component-targets-test.zip     Text File diffs.patch     Text File diffs.patch     File jsf-systest.war     File jsf-systest.war    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-901 Deprecate "targets" concept Closed
Issuezilla Id: 755
Status Whiteboard:

cat2 frame size_medium importance_large


 Description   

I already talked to Ed Burns about this at the JSFDays, but I thought opening a
spec issue won't be bad!

There are 4 special attributes on composite components (action, actionListener,
validator, valueChangeListener) which are not populated on #

{cc.attrs}

as
MethodExpressions, but added to their related components (defined via the
targets attribute of cc:attribute) directly via setAction(), addActionListener(),...

This works fine for all standard components. However if you nest another
composite component inside the implementation of our composite component, you
are not able to pass any of those 4 attributes through to the nested composite
component, because it (normally) is a UINamingContainer which does not implement
any of the needed interfaces.

To make this more clear imagine you have a composite component which is a
special commandButton (AJAX-commandButton or whatever) and you're creating e.g.
a LoginPanel composite component. This LoginPanel composite component has an
actionListener attribute to determine the actionListener for the login button
(which in our implementation is our composite component commandButton). Now we
are not able to pass the actionListener through to "our" commandButton, because
it is no ActionSource2 an the MethodExpression is not stored in
#

{cc.attrs.actionListener}

. The same applies to the 3 other attributes.

<cc:interface name="loginPanel">
<cc:attribute name="actionListener" targets="???" />
</cc:interface>
<cc:implementation>
<!-- other components -->
<ez:customCommandButton actionListener="???" />
</cc:implementation>



 Comments   
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 [ 08/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 ganeshpuri [ 13/Oct/10 ]

I ran into this with my first large scale JSF 2.0 customer within a few days and
I think it should be urgently fixed, because usage of action, actionListener,
validator and valueChangeListener is essential to composite components and
nesting them will happen as soon a they are used in non trivial projects.

Comment by Ed Burns [ 13/Oct/10 ]

I am delighted to report that now taking the time to look at this more
closely, I observe that it appears to work.

In fact, we have an automated test and I'm about to attach the war.

Deploy the war and visit

http://localhost:8080/jsf-systest/faces/composite/nesting03.xhtml

Click the button. It works if you are navigated to a page with
<title>Navigation Result</title>.

The key enabler is you must declare the cc-relative client-id in the
targets.

SECTION: Using Page nesting03.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"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:ez="http://java.sun.com/jsf/composite/composite">
<head>
<title>Nesting 03</title>
</head>
<body>
<h:form>
<ez:nesting3 action="#

{compositeBean.doNav}

" />
</h:form>
</body>
</html>

SECTION: Defining Page nesting3.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"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:composite="http://java.sun.com/jsf/composite"
xmlns:ez="http://java.sun.com/jsf/composite/composite">
<head>
<title>Should Not Be Displayed</title>
</head>
<body>
<composite:interface>
<composite:attribute name="action" required="true" method-signature="String method()"
targets="wrapper:commandButton"/>
</composite:interface>
<composite:implementation>
<ez:wrapper id="wrapper">
<h:commandButton id="commandButton" value="Click Me" />
</ez:wrapper>
</composite:implementation>
</body>
</html>

SECTION: Managed Bean CompositeBean.java

public String doNav()

{ return "nestingNav"; }
Comment by Ed Burns [ 13/Oct/10 ]

Created an attachment (id=304)
mojarra systest.war

Comment by Jakob Korherr [ 13/Oct/10 ]

REOPENING

Thanks for looking into this, Ed, but unfortunately you got our scenario wrong.
Your scenario works, but imagine the following implementation section of nesting3:

<composite:implementation>
<ez:someOtherNestingComponent action="????" />
</composite:implementation>

and the page for someOtherNestingComponent:

<composite:interface>
<composite:attribute name="action" required="true"
method-signature="String method()" targets="commandButton"/>
</composite:interface>
<composite:implementation>
<h:commandButton id="commandButton" value="Click Me" />
</composite:implementation>

Thus you have a composite component with an action attribute that itself uses a
composite component with and action attribute that itself uses a
h:commandButton. How can you accomplish that?

Or to be more specific: what do you use for the action attribute of the inner
composite component since action is not published as #

{cc.attrs.action}

and how
do you prevent the ClassCastException for ActionSource2 for the inner composite
component (since the first composite component tries to retarget the action
listener to it)?

Is this enough documentation or should I provide a sample webapp?

Comment by Ed Burns [ 13/Oct/10 ]

Ahh, thanks for reopening this.

I have modified the systest and will attach a patch and a new version of it.

Deploy it and you can reproduce the problem by visiting
http://localhost:8080/jsf-systest/faces/composite/nesting09.xhtml

Comment by Ed Burns [ 13/Oct/10 ]

Created an attachment (id=305)
patch to systest that shows off the bug.

Comment by Ed Burns [ 13/Oct/10 ]

Created an attachment (id=306)
systest with patch applied.

Comment by Ed Burns [ 13/Oct/10 ]

I'm really sorry to do this, but we simply don't have time to make this into 2.1.

If someone wants to submit a patch, maybe we can get it in under the wire. If so, I suggest they start by
taking a look at FaceletViewHandlingStrategy.java, line 1408:

((ActionSource2) target)
.setActionExpression(
new ContextualCompositeMethodExpression(((sourceValue instanceof ValueExpression)
? (ValueExpression) sourceValue
: null),
me));

}

This is where the ClassCastException mentioned by Jakob originates.

I'd approach a first approximation of this feature by introducing some isCompositeComponent() test
there and take action accordingly.

Comment by Ed Burns [ 25/Oct/10 ]

On Friday 22 October at 18:33 EDT, Martin Marinschek wrote:

MM> Hi guys,

MM> my strong believe is that the target attribute should be immediately
MM> deprecated.

MM> It is wrongly placed where it is right now - an interface definition
MM> should never provide hooks into the implementation. It should only
MM> provide a meaningful context to which the implementation can refer.

The targets attribute is central to the entire concept of composite
components. I assert that it does not constitute a violation of the
abstraction because the targets attribute is not intended for
consumption by the page author. In fact, it is an implementation detail
that happens to reside within the <cc:interface> section.

MM> I am sorry I haven't voiced this objection before - but at the time
MM> this was discussed I was not very active on the EG, and then it was
MM> too late to talk about this.

Yes, I'll say! I recall that we talked about this in December 2007. I
know because we had the EG meeting while I was in the hotel at
JavaPolis and I remember such a unique venue.

>>>>> On Tue, 19 Oct 2010 14:30:17 -0500, Leonardo Uribe <lu4242@gmail.com> said:

LU> I like the way it works now. For example, tomahawk t:inputHtml
LU> component was rewritten into a composite component, and it is a good
LU> example about when it could be useful that the only requerimiento
LU> for a component to be composite is implement NamingContainer:

For what it's worth, Leonardo is happy with this way it works, provided
we address his other issues.

On Sat Oct 23 03:46:13 EDT 2010 Ganesh wrote:

G> Martin, I like your proposal on deprecating "targets". But how would
G> you then handle this case: Using a cc I nest <f:actionListener
G> "for=a" ... /> and inside the cc there is a <cc:actionSource name="a"
G> targets="b, c" /> where b and c are buttons? The logic of the "for"
G> attributes only includes this: "If present, this attribute refers to
G> the value of one of the exposed attached objects within the
G> composite component inside of which this tag is nested." IMO
G> deprecating "targets" would require opening "for" to refer to
G> multiple exposed attached objects within the composite component
G> inside of which this tag is nested just the way targets is doing this
G> right now. "targets" kind of bundles them right now.

Yes, exactly. There was a lot of back and forth between David Geary,
Ken Paulsen, Kito Mann, Andy Schwartz, and myself on this.

G> To make this more convenient omitting "for" could simply be a synonym
G> representing a "for" for all nested actionSources, actionSource2s
G> and CCs.

I prefer to be explicit here.

G> Please follow Jakob's proposal on adding action, actionListener,
G> valueChangeListener and validator the attributes map
G> (#

{cc.attrs.action}, #{cc.attrs.actionListener},
G> #{cc.attrs.valueChangeListener}, #{cc.attrs.validator}). This is what
G> a developer would expect to happen (at least I did so) and one could
G> easily pass them on to nested components.

JK> I think we should do this a little differently:

JK> 1) try to add the e.g. ActionListener to the component specified in
JK> the targets attribute, if possible. If it is not possible, log a
JK> warning.

JK> 2) also expose the "well-known" attributes ("action",
JK> "actionListener", ...) on the composite component attribute map, this
JK> means being able to access the action attribute via #{cc.attrs.action}

JK> (currently not possible, because those attributes are not put on the
JK> attribute map).

JK> Thus the user can use the targets attribute if he/she wants to (and of
JK> course, if it is possible) and also use #

{cc.attrs.action} to refer to
JK> the action attribute (like to any other attribute).

JK> Frankly I really don't understand why this was separated in the first
JK> place. Of course, the targets attribute is neat, but IMHO it is also
JK> kinda confusing. I find it a lot easier to access every attribute
JK> (regardless if well-known or custom) via #{cc.attrs.attributeName}.
JK> Furthermore using this approach you can support nesting normal
JK> components and also nesting composite components.

JK> In addition the targets attribute can't solve a scenario in which the
JK> action attribute of the inner component is required (most likely the
JK> attribute from a composite component), because you need to enter a
JK> value for the attribute, but you currently can't use
JK> #{cc.attrs.action}

, because this one points "nowhere".

Comment by lu4242 [ 26/Oct/10 ]

Created an attachment (id=319)
Patch to use cc.attrs.action EL

Comment by lu4242 [ 26/Oct/10 ]

Created an attachment (id=320)
Test demo using maven. To run type: mvn clean -Djsf=mojarra jetty:run

Comment by lu4242 [ 26/Oct/10 ]

Created an attachment (id=321)
WAR file from test project

Comment by Ed Burns [ 27/Oct/10 ]

Thanks for the patch. I'm evaluating it now.

Comment by Ed Burns [ 27/Oct/10 ]

I applied the patch and re-ran a test page I had previously authored (on 13 October) and still see the
ClassCastException.

Can you please rework the patch to fix that?

Thanks,

Ed

This time I'll attach a zip of the simple xhtml files.

Comment by Ed Burns [ 27/Oct/10 ]

Created an attachment (id=325)
zip of composite component files

Comment by lu4242 [ 29/Oct/10 ]

Created an attachment (id=330)
Patch solving problem cc:attribute targets to nested composite components

Comment by lu4242 [ 29/Oct/10 ]

Created an attachment (id=331)
WAR file from test project

Comment by lu4242 [ 29/Oct/10 ]

Created an attachment (id=332)
Test demo using maven. To run type: mvn clean -Djsf=mojarra jetty:run

Comment by lu4242 [ 03/Nov/10 ]

Created an attachment (id=335)
Full solution merging two previous patches

Comment by Ed Burns [ 04/Feb/11 ]

Snapshot of reproducer, in progress.

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-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-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-1008] Add ability for define tag to append to an existing definition Created: 22/May/11  Updated: 12/Aug/14

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

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


 Description   

In Facelets one can use a ui:define tag to define content in a template client. This named content can be inserted into a template by using ui:insert.

When the template client that defines the content is itself a template, its template client may also want to contribute to this content, typically by appending to it. This is currently not possible. The template needs to use a new ui:insert tag with a new name.

E.g.

template.xml

<f:view>            
    <ui:insert name="links"/>        
</f:view>

general.xml

<ui:composition template="template.xhtml">     
   <ui:define name="links">
         <h:link ... />
         <ui:insert name="links1"/>    
   </ui:define>        
 </ui:composition>

orders.xml

<ui:composition template="general.xhtml">     
   <ui:define name="links1">
      <h:link ... />
      <ui:insert name="links2"/>     
   </ui:define>        
 </ui:composition>

etc

Instead of manually 'chaining' defines and inserts in this way, Facelets could define tags or attributes for contributing to existing definitions. E.g.:

general.xml

<ui:composition template="template.xhtml">     
   <ui:append name="links">
      <h:link ... />    
   </ui:append>        
 </ui:composition>

orders.xml

<ui:composition template="general.xhtml">     
   <ui:append name="links">
      <h:link ... />    
   </ui:append>        
 </ui:composition>

Instead of introducing a new ui:append tag, a contribute="append" on ui:define could be used instead. Next to appending, prepending could be considered via a ui:contribute tag or contribute="prepend" attribute.



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





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

[JAVASERVERFACES_SPEC_PUBLIC-322] Add interfaces to javax.faces.component package Created: 21/Nov/07  Updated: 04/Aug/14

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

Type: Sub-task Priority: Major
Reporter: mwessendorf Assignee: Unassigned
Resolution: Unresolved Votes: 8
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-236 UIData is Fundamentally Broken and Ne... Closed
Issuezilla Id: 322
Status Whiteboard:

EGTop5 effort_moderate cat2 javadoc size_medium importance_medium draft


 Description   

There are currently nice interfaces, like ValueHolder and EditableValueHolder.
But this isn't enough.

The minimal contract of creating a (custom) JSF component is UIComponent.
It is not necessary to extend something like UIComponentBase or even UIInput,
which is good.

For instance for checking if a component is able to be validated, some do a
instanceof UIInput, which would fail in some cases (as in Trinidad). Luckily
enough, we have the EditableValueHolder interfaces, so checking against that is
fine.

I noticed a lot of issues in the past with UIForm, since there is not "Form"
interface for that. One of the issues, when making Tomahawk working with
Trinidad/ADF Faces was that the Trinidad/ADF Faces form isn't extending UIForm
(which isn't wrong). We ended up, using a String-based identifier (component
family) for ensuring the component (from Trinidad) is a form. With an interface
for Form (like for EditableValueHolder) there weren't a need for "checking Strings".

This is true for "table components" as well. A "table interface" would be nice.



 Comments   
Comment by mwessendorf [ 19/Aug/08 ]

On an interface for "Form", I can think about things like:
-autoComplete
-usesUpload (bool, when TRUE => set enctype="multipart/form-data")
(and/or enctype)
-prependId
-defaultCommand (executed when hitting ENTER inside the form)

On an interfaces for Tables (call it structuredData or so, since it could be
implemented in a custom Tree, for instance) I can think of these:
-var ?
See Trinidad's UIXCollection CLASS, which is the base for all structured Data
(in Trinidad):
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/component/UIXCollection.html

Again such a "generic" interfaces could be useful when creating tree's (instead
of extending UIData (like Tomahawk or the Hans Bergsten book).

But... it is really important to have STRONG types, instead of messing around
with Strings (component family)

Comment by Ed Burns [ 21/Aug/08 ]

Add status whiteboard: EGTop5

Comment by Ed Burns [ 12/Sep/08 ]

effort_moderate

Comment by Ed Burns [ 12/Sep/08 ]

change target_milestone to 2.0

Comment by Ed Burns [ 17/Sep/08 ]

As discussed at JSFOne, I think we need a behavioral interface for components that manage collections of
children, such as trees, tables, and such.

Comment by Ed Burns [ 15/Oct/08 ]
      • Issue 189 has been marked as a duplicate of this issue. ***
Comment by kito75 [ 16/Oct/08 ]

It'd make sense to expose a isPostBack() method (which I think is on
FacesContext in 2.0) through the Form interface, as well.

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

We just didn't get to this one. Sorry Matzew.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by Ed Burns [ 24/Feb/10 ]

I really don't think this is a P1 also.

Comment by kito75 [ 24/Feb/10 ]

Matthias, aren't your example form properties more renderer-specific?

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

javadoc

Comment by Ed Burns [ 22/Mar/10 ]

components

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 04/Aug/14 ]

Target for 2.3





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

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

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

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

 Description   

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



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

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

Comment by arjan tijms [ 11/Jul/15 ]

Expanded @FacesDataModel support to UIRepeat

Comment by arjan tijms [ 13/Jul/15 ]

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

Comment by Manfred Riem [ 13/Jul/15 ]

Can you please address the following PMD issues

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

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

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

Comment by arjan tijms [ 14/Jul/15 ]

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

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

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

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

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

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

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

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

Comment by arjan tijms [ 14/Jul/15 ]

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

Comment by arjan tijms [ 15/Jul/15 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-916] Support for generic types in Composite Component's attribute @type and @method-signature Created: 09/Dec/10  Updated: 12/Aug/14

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

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

Status Whiteboard:

size_large importance_medium

Tags: 3_1-exclude

 Description   

Currently there is no way to infer type of cc:attribute's type, since you can only use fully qualified name of class like:

<composite:interface>
<composite:attribute name="value" type="java.util.List"/>
</composite:interface>

This is not sufficient for tools to implement features like validation and code completion of EL expressions inside <cc:implementation>

Allow definition of generic types in @type and @method-signature to improve composite component's usability:

<composite:interface>
<composite:attribute name="value" type="java.util.List<my.package.Person>"/>
</composite:interface>



 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-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-598] Allow a URL target for outputScript and outputStylesheet Created: 30/Jul/09  Updated: 12/Aug/14

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

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

cat2 vdldoc javadoc size_small importance_small


 Description   

both outputStylesheet and outputScript should be able to take a URL instead of a
resource target - there are times when you want to serve things from someone
else's machine, such as Yahoo or Google.

One use case for this change: You are writing a composite component, which uses
Google's service to load CSS (such as when you use the YUI components). This
means that you currently must either require users to put a <link> tag in the
header, which is clearly undesirable, or that you need to use only local files,
which can in many cases offer worse performance.



 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 Ed Burns [ 24/Feb/10 ]

I agree with the intent of the issue, but it's too big for 2.0 Rev a

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 04/Mar/10 ]
      • Issue 706 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 22/Mar/10 ]

vdldoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 04/Aug/14 ]

Leave unchanged.





[JAVASERVERFACES_SPEC_PUBLIC-1238] Enhance component referencing / findComponent Created: 15/Nov/13  Updated: 20/Jun/16

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

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


 Description   

Currently component referencing with the JSF API is very limited.
Keywords can currently only be used with f:ajax and not for e.g. outputLabel "for" attribute.
Also keywords cant be combined and we dont even have many keywords.

For PrimeFaces, i created a small modular API to enhance the search alogorithm as you can read here:
http://blog.primefaces.org/?p=2740

Noteable features are:

  • keywords can be used for all components
  • combinable keywords like @composite:@parent or @form:myId
  • currently a (limited) pluggable framework to allow new keywords for endusers

For the JSF API, a new artifact for resolving expression for findComponent (like ViewHandler etc.) would be great and can easily be enhanced by component libraries.
Maybe something like "ComponentExpressionResolver".

If its somehow possible, i would like to help to create and finalyze the API.

Sorry for Issue 1237 - please close it.



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

This area is very sensitive to performance problems.

Comment by tandraschko [ 26/Sep/15 ]

The performance won't be affected for existing applications as the new search expression logic is only used if the whole expression string contains a "@".
Some expressions are faster, some are slower but the overall performance is very good and i did a lot of optimization for it.

Would great to see it in the next API release. BootsFaces implemented a similiar API.
As i said, i would take care of it and would contribute my ideas to the JSF API.

Comment by stephanrauh [ 26/Sep/15 ]

I agree with Thomas. I consider the advanced search expressions very useful. So useful, that I implemented them in BootsFaces 0.8.0 myself. As for the performance considerations: granted, we should keep the performance in mind. However, I'm using the PrimeFaces search expressions for years now without noting a performance penalty. In particular, the expressions I use most frequently - @parent, @next and @previous - are implemented in a very efficient way.

Comment by balusc [ 20/Jun/16 ]

This is one of the things I'd like to see in JSF 2.3 as well. Community contribution is very welcome.





[JAVASERVERFACES_SPEC_PUBLIC-1227] Add <f:protectClientWindowOpenInNewTab> JavaScript behavior tag Created: 07/Oct/13  Updated: 17/Sep/15

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

Comment by muellermi [ 17/Sep/15 ]

The idea behind this issue only protects the browser to open a new tab or window using the same client id.

Sadly the user still is able to copy the url and paste it into a manually opened new tab. What we really need is some information to determine the "right" window.

Comment by muellermi [ 17/Sep/15 ]

Maybe window.name (JavaScript) would be helpful to perform this task.

Comment by tandraschko [ 17/Sep/15 ]

window.name is also used in DeltaSpike.
Please have a look at it: http://deltaspike.apache.org/documentation/jsf.html#AvailableModes
CLIENT_WINDOW is the most complete and 100% working mode.

I will complete the docu these days, LAZY mode is described much more detailed.





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

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

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

Status Whiteboard:

size_small importance_medium


 Description   

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

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



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

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

Comment by arjan tijms [ 08/Aug/11 ]

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

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

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

And finally two (perhaps) more exotic helper methods:

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

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

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

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

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

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

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

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

Comment by arjan tijms [ 15/Oct/11 ]

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

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

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

It gets more verbose when i18n is involved:

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

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

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

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

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

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

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

Overloaded to add message to specific component:

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

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

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

Comment by tedgoddard [ 21/Feb/12 ]

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

helper = new FacesServletHelper(facesContext)

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

Comment by arjan tijms [ 21/Feb/12 ]

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

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

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

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

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

Comment by kithouna [ 28/Jan/13 ]

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

Comment by kito75 [ 27/Jun/14 ]

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-795] UIViewParameter state saving algorithm Created: 12/May/10  Updated: 01/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 795
Status Whiteboard:

size_small importance_medium


 Description   

From the mail "State saving of UIViewParameter" on jsr-314-open:

UIViewParameter uses the submittedValue to store its value in the state for the
next postback, because obviously the view parameter won't be in the request
parameter map of the next request (which is the postback). But because its
submittedValue is null after the conversions and validations, it has to be set
again before the state is generated. To accomplish that, the spec currently
states to override encodeAll() and make the call to setSubmittedValue() there.
In addition, encodeAll() has to be called in UIViewRoot.encodeEnd() for every
UIViewParameter in the view. This works perfectly for normal requests, but when
you are using an AJAX request the state is generated before
UIViewRoot.encodeEnd() is called an thus the submittedValue for every
UIViewParameter is null in the state. This means that the value of every
UIViewParameter will be null in the following request.

Now the easiest solution to this problem, which I also already committed to
MyFaces trunk (again see [1] for details), is to do mostly the same as in
UIViewRoot.encodeEnd() just also in PartialViewContext.
processPartial() when the PhaseId is RENDER_RESPONSE before the state is
generated to make it work for AJAX-requests.

However I don't really like this solution, because we have to think of handling
UIViewParameters in a special way every time we change something on any render
mechanism. Why don't we just override saveState() on UIViewParameter and set the
submittedValue there before the state is saved. This will have the same result,
but without the code in UIViewRoot, PartialViewContext and
UIViewParameter.encodeAll() and without future headaches. I also already
uploaded a patch for this to the MyFaces issue at [1].

Answer to this from Martin Marinschek: "This is just a so much better solution
. We should spec this one."

[1] https://issues.apache.org/jira/browse/MYFACES-2645



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

Move to 2.1.

I agree with this approach.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by kithouna [ 28/Feb/13 ]

Was anything ever done for this one?

Comment by nullone [ 28/Feb/13 ]

Myfaces team took 3 days to review and accept the fix, and Mojarra team could not do the same thing for more than 33 months, and still saw no light.

Is that really amazing or the team is sleeping on its way?

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Set priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-749] using JSF as template engine Created: 18/Feb/10  Updated: 01/Aug/14

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

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

Operating System: All
Platform: All


Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-477 Render a view programatically Closed
Issuezilla Id: 749
Status Whiteboard:

cat2 frame size_medium importance_large draft


 Description   

There is no easy way to get result from rendering of JSF page without going to
browser.
It would be very useful to have possibility directly initiate rendering of the
page and get corresponding result from it. Ability to use this approach will
allow developers easily adapt JSF as powerful template engine. In my case we
are using JSF as template engine to render HL7 messages. Also this functionality
would be helpful for testing purposes. For example "FacesTester" project
included some additional code just because there are a needs to get result of
rendering directly in java code.



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

cat2

Comment by vladperl [ 08/Mar/10 ]

It seems issue
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=477 is
relevant to this one.

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 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by rdelaplante [ 07/Jul/10 ]

Please consider providing the ability to sandbox the EL context. An example use
case is allowing users to edit email templates. I would want the users to be
able to access only the model objects my application provides to the template.
I do not want the user to gain full access everything in the application through EL.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 20/Dec/13 ]

This will probably be the top feature in JSF 2.3.

Comment by ova2 [ 21/Dec/13 ]

Wow, this would be a killer feature. We need it too for exporting a page to PDF. Currently we use PhantomJS (server-side browser) to call an JSF page to be exported via URL. By means of this new feature we could get an JSF page as a string and pass it direct to PhantomJS without the HTTP overhead.

Comment by tony.herstell [ 30/Apr/14 ]

Craig (see this site) is working on a JSF Mail plugin...
http://reallifejava.com/blog/

As well as Seamy stuff like
simpleBPM
simpleSecuirty

Think:
s/simeple/seam4/g

No promises though.

Comment by Ed Burns [ 01/May/14 ]

Tony, looks good. This is a very useful idea.

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-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: 6
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-1139] Add facets to h:head to enable resource ordering Created: 16/Oct/12  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: Minor
Reporter: amitev Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A few facets could be added to h:head in order to support resource ordering i.e. to declare application resources after component library (framework) resources.

Example:

<h:head>
<f:facet name="begin">
<meta http-equiv="X-UA-Compatible" content="EmulateIE8" />
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
<title>PrimeFaces - ShowCase</title>
</f:facet>

<f:facet name="end">
<link rel="stylesheet" type="text/css" href="#

{facesContext.externalContext.requestContextPath}

/resources/app.css" />
</f:facet>
</h:head>

There is an existing implementation of that in Primefaces using custom renderer. More info could be found here [1].

1 - http://blog.primefaces.org/?p=1433



 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-972] [JSR-303 integration] @Valid support for custom types Created: 15/Apr/11  Updated: 20/Jan/16

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

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-543 @Valid and JSF Sub-task Open  

 Description   

see https://issues.apache.org/jira/browse/EXTVAL-96



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

This issue is related to JAVASERVERFACES_SPEC_PUBLIC-543

Comment by Ed Burns [ 06/Jun/11 ]

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 20/Jan/16 ]

<os890> JAVASERVERFACES_SPEC_PUBLIC-972 is quite simple to fix (EXTVAL-96 took just few lines) - in combination with jsf-1 something additional needs to get specified - like: ignore global error-messages if they have the same source as an inline message (the bv api provides that info)

Comment by Ed Burns [ 20/Jan/16 ]

<os890> well - a patch for the spec. is easy - "The validation-process for properties bound to input-components based on BV needs to follow the BV rules for @Valid" any other rule is up to the wording for JAVASERVERFACES_SPEC_PUBLIC-1.

Comment by Ed Burns [ 20/Jan/16 ]

<edburns> Can you find the exact context in which to apply your spec edit and add that to the issue?
<edburns> I have to focus on another task right now. Thanks for bringing it to my attention.
<os890> let me check
<os890> imo section 3.5.6





[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





Relative Resources (JAVASERVERFACES_SPEC_PUBLIC-947)

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

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

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

Operating System: All
Platform: All


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

size_small importance_medium


 Description   

Consider a stylesheet

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

Resources are loaded with URLs such as

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

(when prefix mapping is used).

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

.ui-icon

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

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

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

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

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

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

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

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

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

javax.faces.RESOURCE_URL_MAPPING with options prefix and param

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

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


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

2.2

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by ramiromagalhaes [ 14/Apr/11 ]

This is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900.

Comment by lamine_ba [ 14/Apr/11 ]

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

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

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

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

If would be nice if we could come back to this

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

Comment by Jakob Korherr [ 15/Apr/11 ]

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

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

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-872] The View Metadata tag is not processed unless at least one <f:viewParam> is defined Created: 29/Jul/10  Updated: 12/Aug/14

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

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

Operating System: Linux
Platform: PC


Issuezilla Id: 872
Status Whiteboard:

size_medium importance_medium


 Description   

Section 2.2.1 of the JSF 2 spec requires that if no view-parameters exist in the
view-metadata, that the render response phase be invoked immediately following
the current phase on a GET request. This prevents custom metadata from being
provided that may require lifecycle processing (view-actions, for example.)

This is a hindrance to creating custom metadata-since even if a tool (such as
prettyfaces) wishes to add custom url-parameter handling (or custom action
invocation), it must also add an empty view-param in order to trigger the
lifecycle. Also, not many people expect this behavior, since it is relatively
counter-intuitive.

I propose defining a new contract that would allow for individual meta-data
components to determine whether or not the full lifecycle should be invoked:

public interface ViewMetadata {
/**

  • If true, the full faces lifecycle will be invoked; if false, the
  • lifecycle will skip directly to render-response, unless another
  • {@link ViewMetadata}

    object requests that the lifecycle be executed.
    */
    public boolean requiresLifecycle();
    }

This new contract would still honor the behavior of previous implementations,
and should be mostly backwards compatible (because unless the custom tag
requests the lifecycle, it will still be skipped.)

The current spec verbiage:

2.2.1 - "If the request is not a postback, try to obtain the
ViewDeclarationLanguage from the ViewHandler, for the current viewId. If no such
instance can be obtained, call facesContext.renderResponse(). Otherwise, call
getViewMetadata() on the ViewDeclarationLanguage instance. If the result is
non-null, call createViewMetadata() on the ViewMetadata instance. Call
ViewMetadata.getViewParameters(). If the result is a non-empty Collection, do
not call facesContext.renderResponse(), otherwise do call
facesContext.renderResponse(). If it turns out that the previous call to
createViewMetadata() did not create a UIViewRoot instance, call createView() on
the ViewHandler. Call renderResponse() on the FacesContext."



 Comments   
Comment by lincolnbaxter [ 29/Jul/10 ]

I'd like to revise my proposal; I now oppose my original suggestion of adding a
new interface:

Solution:

It's possible we could just get away with changing the verbiage a little bit in
order to resolve this issue, thereby avoiding changes to any existing, or adding
any new APIs. (Note the **starred** change.) The change is very subtle, and
not very invasive, but perfectly addresses this situation.

The current spec verbiage:

2.2.1 - "If the request is not a postback, try to obtain the
ViewDeclarationLanguage from the ViewHandler, for the current viewId. If no such
instance can be obtained, call facesContext.renderResponse(). Otherwise, call
getViewMetadata() on the ViewDeclarationLanguage instance. If the result is
non-null, call createViewMetadata() on the ViewMetadata instance. ***Call
ViewMetadata.getViewParameters()***. If the result is a non-empty Collection,
do not call facesContext.renderResponse(), otherwise do call
facesContext.renderResponse(). If it turns out that the previous call to
createViewMetadata() did not create a UIViewRoot instance, call createView() on
the ViewHandler. Call renderResponse() on the FacesContext."

Proposed verbiage:

2.2.1 - "If the request is not a postback, try to obtain the
ViewDeclarationLanguage from the ViewHandler, for the current viewId. If no such
instance can be obtained, call facesContext.renderResponse(). Otherwise, call
getViewMetadata() on the ViewDeclarationLanguage instance. If the result is
non-null, call createViewMetadata() on the ViewMetadata instance. ***Call
ViewMetadata.getChildren()***. If the result is a non-empty Collection, do not
call facesContext.renderResponse(), otherwise do call
facesContext.renderResponse(). If it turns out that the previous call to
createViewMetadata() did not create a UIViewRoot instance, call createView() on
the ViewHandler. Call renderResponse() on the FacesContext."

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

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

Comment by arjan tijms [ 20/Mar/13 ]

I think this is an exact duplicate of JAVASERVERFACES_SPEC_PUBLIC-762.

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-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-810] Access to component ancestor chain during Facelets handler processing Created: 25/May/10  Updated: 12/Aug/14

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 810
Status Whiteboard:

size_large importance_medium

Tags: adf

 Description   

We have various JSP tag implementations that walk up the component ancestor chain during tag execution
for one reason or another. While porting these tags to Facelets, we have been forced to work around the
fact that Facelets does not connect the ancestor chain until after children have been processed.

While it may be too late to change Facelets behavior now, it would be helpful to provide access to the
ancestor chain through some API so that Facelets handlers can interact with parent/ancestor components.



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

2.1.

Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-759] add message attribute to f:validateLongRange etc. Created: 03/Mar/10  Updated: 01/Aug/14

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

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

cat2 vdldoc size_small importance_large


 Description   

It seems very unnatural for me to not have a "message" or "validatorMessage"
attribute on the following tags:

f:validateDoubleRange
f:validateLength
f:validateLongRange
f:validateBean
f:validateRegex
f:validateRequired
f:validator

while I can set a single validatormessage on, e.g. the h:inputText tag alone.

If I have multiple validators on one tag, I want to tell the user which
validation failed with a custom message. This is not possible currently
without creating an own validator that handles the different cases, although
all the required components do already exist and just need to be chained
together.



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

cat2

Comment by Ed Burns [ 22/Mar/10 ]

vdldoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

sheetalv

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Set priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-529] cannot set "title" attribute for "option" elements in a select (f:selectItem) Created: 25/Feb/09  Updated: 01/Aug/14

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

Type: Bug Priority: Minor
Reporter: captainvoid 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
URL: http://forums.java.net/jive/thread.jspa?messageID=330282


Issuezilla Id: 529
Status Whiteboard:

cat2 vdldocs size_small importance_small


 Description   

There's no way to set the title attribute of an HTML option element with the
f:selectItem tag.
The title attribute of an option element is valid HTML and is interpreted by
most browsers as a tooltip.



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

Updating target milestone for 2.0 rev A. If you disagree, now's the time to speak
up!

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

vdldocs

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 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage rkit docs

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-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-237] ResponseWriter write escape arg Created: 25/Jan/07  Updated: 01/Aug/14

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

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


Issuezilla Id: 237
Status Whiteboard:

EGTop5 effort_hard size_medium importance_medium draft


 Description   

Consideration: add optional escape boolean arg to ResponseWriter write methods
to control escaping.

See: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=464



 Comments   
Comment by rogerk [ 19/Mar/08 ]

Targeting for 2.0.

Comment by josefreire [ 20/Mar/08 ]

This issue is relevant when building a <f:selectOneMenu> and one of the
SelectItem has an itemValue that contains Unicode characters (like ç, á, ã).

On submit the validation fails due to the invalid characters.

This is a serious issue because many applications have decode tables that are
build by interface from outside systems, and one day you can wake up with a
broken application.

The workaround is to manually escape (using for example
StringEscapeUtils.escapeHtml) when building the SelectItems and unescaping
manually on receive.

The current behavior is always escaping itemValue, so this leads to a
double-escaping issue.

However, I believe this problem might be solved by changing the validation, and
not changing the ResponseWriter.

Looking at the HTML4 Spec I have found no hint that the existing restrictions on
Unicode characters should ever exist for itemValue since the "value" attribute
on the <OPTION> element is defined as CDATA, so Unicode characters should be
allowed.

I think the validation of the itemValue should be relaxed to allow more complex
values, like strings with Unicode characters.

Comment by rogerk [ 22/Aug/08 ]

Status Whiteboard

Comment by Ed Burns [ 12/Sep/08 ]

effort_hard

Comment by Ed Burns [ 12/Sep/08 ]

change target_milestone to 2.0

Comment by Ed Burns [ 28/Jul/09 ]

Pushing to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by rogerk [ 20/Jan/10 ]

Target 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 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-1419] Support new Html5 events like oninput Created: 07/Jun/16  Updated: 30/Jul/16

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

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


 Description   

e.g. HtmlInputText#EVENT_NAMES should contain oninput

We should actually check the list, all JSF components and add missing events:
http://www.tutorialspoint.com/html5/html5_events.htm

IMO it's important for 2.3 to be more compliant with HTML5.



 Comments   
Comment by WarriorDog [ 30/Jul/16 ]

I"d suggest this one http://www.w3schools.com/tags/ref_eventattributes.asp





[JAVASERVERFACES_SPEC_PUBLIC-1253] Consider enabling abandoning a flow directly for another flow Created: 17/Jan/14  Updated: 01/Aug/14

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

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

Attachments: Zip Archive i_spec_1253-reproducer.zip     Text File i_spec_1253.patch    

 Description   

Consider an app with this arrangement.

src/main/webapp/WEB-INF/faces-config.xml
src/main/webapp/flowA/flowA-flow.xml
src/main/webapp/flowA/flowA.xhtml
src/main/webapp/flowB/flowB-flow.xml
src/main/webapp/flowB/flowB.xhtml
src/main/webapp/flowC/flowC-flow.xml
src/main/webapp/flowC/flowC.xhtml
src/main/webapp/index.xhtml
src/main/webapp/site-template.xhtml

All .xhtml pages in this app are template clients of
site-template.xhtml. The site-template.xhtml has a row of buttons along
the top that allow immediate navigation to all of the flows. The intent
is that whatever flow you're in, you want to abandon it and enter the
new flow when the corresponding button is clicked. This is not a flow
call, but rather should be treated as an atomic "abandon/enter".

The current specification does not support this cleanly.



 Comments   
Comment by Ed Burns [ 17/Jan/14 ]

Diff of reproducer.

Comment by Ed Burns [ 17/Jan/14 ]

zip of reproducer.

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-1223] Facelet ui:param doesn't work in composite components (action) Created: 26/Mar/13  Updated: 01/Aug/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1222 ValueChange method in POJO doesn't re... Open

 Description   

If i have a facelet file which includes a composite component and I want to pass ui:params for the action it doesn't work

File a.xhtml includes my template myTemplate.xhtml. I want to pass parameters for an action

<ui:include src="/pages/templates/myTemplate.xhtml">
      <ui:param name="resetAction" value="reset" />
      <ui:param name="bean" value="#{myBean}" />
</ui:include>

Following works / works not in myTemplate.xhtml:

value is displayed

<h:outputText value="Bean: #{bean}" />

value is displayed

<h:outputText value="resetAction: #{resetAction}" />

Action doesn't work if i pass it into a compositeComponent

<myCom:reset resetAction="#{bean[resetAction]}" />

for a commandButton it works.

<p:commandButton value="test reset" action="#{bean[resetAction]}" />

If I don't add my composite component to a facelet tempalte the action also works:

<myCom:reset resetAction="#

{myBean.reset}

" />



 Comments   
Comment by Manfred Riem [ 09/Apr/13 ]

Can you send the entire reproducer (including all the sources) to issues@javaserverfaces.java.net?

Comment by dasago [ 10/Apr/13 ]

I send you an example project.. (maven based, JBoss 6.0 Final, Mojarra 2.1.17, PrimeFaces 3.5, Omnifaces 1.4.1)

First example in reset page works - pass values directly to composite component

Second example in reset page doesn't work - pass values via facelet file to composite component

Third example in reset page works - pass values via facelet file to composite component with a workaround of omnifaces

Comment by Manfred Riem [ 30/Aug/13 ]

You have hit upon an area with respect to composite components and ui:include that has not been ironed out as much as needed. The problem is that the context of the ui:param is not available within a retargetted expression that the action needs to actually work.

I am moving this to the spec issue tracker as the real issue still exists.

Comment by Thomas Lee [ 30/Aug/13 ]

This is probably a better description of the JAVASERVERFACES_SPEC_PUBLIC-1222 issue I filed. Being a POJO or a managed bean is unrelated if I recall correctly.

I've been working around this by placing the ui:param in the view outside of the ui:include so that evaluations can find the ui:param correctly.

<ui:param name="pojoOrManagedBean" value="#{bean}"/>
<ui:include src="innerPageWithCompositeComponentWithTarget"/>
Comment by Ed Burns [ 13/Sep/13 ]

Manfred, do you think we can close 1222 as a duplicate of this one?

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 Major





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

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

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

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

 Description   

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

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

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

E.g.

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

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

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

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

}


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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

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

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

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

Comment by Ed Burns [ 17/Aug/15 ]

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





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

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

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

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

 Description   

Tried the following code:

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

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



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

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

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

Sample A

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

Sample B

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

Either samples should end up with this:

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

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

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

Comment by Bruno Borges [ 13/Aug/13 ]

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

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

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

Comment by jyeary [ 13/Aug/13 ]

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

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

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

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

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

Comment by Bruno Borges [ 13/Aug/13 ]

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

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

Comment by Ed Burns [ 28/Aug/13 ]

From the spec section cited by John and Frank:

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

Consider Bruno's original markup:

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

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

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

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

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

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





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





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

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

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

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

Status Whiteboard:

size_medium importance_small


 Description   

UIRepeat and UIData do pretty much the same: iterate over a collection of items. There should be a common base class for this, encapsulating the complicated logic for saving/restoring and iterating the state of the "rows". Something like "UIIterate".

Writing iterating components is very complicated at the moment. This base class should be easy to extend and also support any kind of data structures, not only "lists". Using an integer for the "row" iterating index is insufficient for creating "tree" components. A string or kind of indexing object would be much more flexible.

UIRepeat and UIData could extend this class and provide the existing interface on top of it.



 Comments   
Comment by Mathias Werlitz [ 21/Apr/11 ]

Well the essential difference between UIData(<h:dataTable>) and UIRepeat is how the iteration is done during render response.
UIRepeat iterates in the component and HtmlDataTable iterates in the renderer. This flexibility should be possible. Iterating in the renderer can be easier for "tree" components.

I could imagine a structure like this:

UINamingContainer
|
UIIterate
|
|- UISequentialIterate
| |
| |- UIData
| |- UIRepeat
|
|- UITree?

At least there should be an marking interface for such components because state saving seems to be different when nesting of iterating components is possible. For example UIRepeat already checks for UIData or UIRepeat parents. UIData does only look for itself as a parent.

Comment by Ed Burns [ 22/Apr/11 ]

I thought we had an issue for this, but yes, it's a good idea.

Comment by arjan tijms [ 27/Mar/14 ]

I think is a very important issue. In general UIData seems to be more robust than UIRepeat, but they indeed do pretty much the same thing and when inspecting the code it also looks like they had similar implementations at one time and/or borrowed from each other.

If there was a common implementation bugs such as JAVASERVERFACES-3215 would probably not have been there.

It would also prevent issues like JAVASERVERFACES_SPEC_PUBLIC-1103. In that case UIData got a new feature that UIRepeat would have needed just as well, but because of the time between JSF releases now has to wait for this for a rather long time.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-960] View params do not support multiple values Created: 01/Apr/11  Updated: 12/Aug/14

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

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

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2230 Add <f:viewParams> for parameters wit... Closed
Status Whiteboard:

size_medium importance_medium


 Description   

HTTP allows multiple values for a request parameter so view params should do the same. <f:viewParam> should support a List or array as the target type of the value.

Maybe a new component <f:viewParams> should be introduced that behaves a bit like <h:select...>, but limiting the possible values may not be required in every case.



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

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

Comment by Ed Burns [ 01/Aug/14 ]

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





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

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

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

All


Status Whiteboard:

size_small importance_large


 Description   

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

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

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

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

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

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

Thanks!

-Ken



 Comments   
Comment by persapiens [ 06/Nov/11 ]

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

Page:

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

{s}

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

My Component (crud):

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

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

{teste.list()}

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

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

Comment by Manfred Riem [ 13/Feb/12 ]

Ken,

Have you tried doing the following?

<cc:implementation>
<h:dataTable>
<f:facet name="header">
<cc:renderFacet name="fooHeader"/>
</f:facet>
</h:dataTable>
</cc:implementation>

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





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

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

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

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

size_medium importance_medium


 Description   

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

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

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

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

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



 Comments   
Comment by lu4242 [ 18/Apr/11 ]

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1396] Standardize WebSocket integration with f:websocket Created: 12/Aug/15  Updated: 06/Dec/16

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

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: balusc
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 8 minutes
Original Estimate: Not Specified

Attachments: Text File JAVASERVERFACES_SPEC_PUBLIC-1396.patch    

 Comments   
Comment by balusc [ 10/Dec/15 ]

Attached a git patch with initial commit of a functional f:socket tag.

As discussed, I dropped SSE support as it isn't standardized and has less browser support (no Microsoft IE/Edge), while WS is standardized, even in Java EE (JSR356), and has better browser support and is more efficient (no persistent open connection).

Comment by balusc [ 14/Dec/15 ]

After testing on various servers I have futher improved the script and logic. Also a new context param is added to explicitly enable the push (lazy initialization turned out to not work on Tyrus WS implementation).

Comment by balusc [ 19/Dec/15 ]

Proposal for PartialViewContext#getEvalScripts() has been splitted to https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1412

Comment by balusc [ 14/Jan/16 ]

Replaced git patch with current f:websocket tag.

Comment by balusc [ 28/Jan/16 ]

Replaced git patch with current f:websocket tag, now with session scope support

Comment by balusc [ 04/Mar/16 ]

Replaced git patch with current f:websocket tag, now with view scope, user-target and CDI event support.

Comment by balusc [ 10/Mar/16 ]

Replaced git patch with current f:websocket tag, now with test case.

Comment by balusc [ 10/Mar/16 ]

Committed and pushed:

https://java.net/projects/mojarra/sources/git/revision/598058f425f8894683f1d68796b0474e54cfea9e

Comment by balusc [ 10/Mar/16 ]

<f:websocket> has been added, along with 2 testcases (one to test context param and another to test three different push channels (app/session/view))

Comment by balusc [ 14/Mar/16 ]

(reopened accidentally closed issue)

Commited improvement as to handling of jsf.js script (refactored utility from AjaxHandler into RenderKitUtils so it can be reused by WebsocketHandler's WebsocketFacesListener). Initial implementation broke state saving.

https://java.net/projects/mojarra/sources/git/revision/ac4253639ed23eace38451fff3c33c6e9780be2b

Comment by balusc [ 14/Mar/16 ]

Test case failed on Hudson with development stage enabled; it has now been fixed.

https://java.net/projects/mojarra/sources/git/revision/9c65817db3c9e80421911692e83319ad8c97ac1e

Comment by balusc [ 18/Mar/16 ]

All tests have passed. Closing out issue.

Comment by balusc [ 27/Oct/16 ]

Reopening to improve spec further.

1. f:websocket needs to be an UIComponent implementing ClientBehaviorHolder
2. jsf.push.init needs to take clientID + full URL
3. jsf.push.open/close needs to take clientID instead of channel
4. ViewHandler should have a getWebsocketURL() or something like that

Comment by balusc [ 06/Dec/16 ]

1. 2. 3. are done. TODO: 4.





[JAVASERVERFACES_SPEC_PUBLIC-1196] CC-like conveniences for Facelet tags Created: 02/Jun/13  Updated: 29/Aug/15

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

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

Tags: ease-of-use, ease_of_development, facelets, tag, taglib

 Description   

In JSF 2.x there are composite components and Facelets tags. A prime difference between these two is that composite components become a component themselves in the component tree, while Facelets tags cause their "child" components to be inserted but they themselves do not become part of the tree.

Both these two artifacts have their own unique use cases, and thus the newer composite component cannot totally replace the older Facelet tags.

However, composite components being the more modern variant have several ease of use features such as the ability for being auto-registering when put into the /resources folder and the definition of its attributes directly into the defining .xhtml file.

Since Facelets tags are still very useful in modern JSF programming, I'd like to request them being upgraded to support auto-registering and attribute definition in the .xhtml file as well.

E.g.

/resources/mytag.xhtml
<ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets">
    
    <ui:attribute name="foo" />
    
    ...
</ui:composition>

The above would register a Facelets tag just like the following in a -taglib.xml would do:

<tag>
    <tag-name>mytag</tag-name>
    <source>tags/mytag.xhtml</source>
    <attribute>
        <name>foo</name>	
    </attribute>
</tag>


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

This is a nice idea.

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 djmj [ 29/Aug/15 ]

What about conditionally allowing composite component's behave like a tag or not to be a naming container?

I don't know much about the implementation background but was a developer these concepts seem much alike with little difference.
I only use tags when i dont want a naming container or i want to render the tag "as is". (for instance in a <h:panelGrid> to produce multiple cells)





[JAVASERVERFACES_SPEC_PUBLIC-1190] Extend facelet-taglib schema Created: 30/Apr/13  Updated: 13/Aug/14

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

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

Tags: facelets, taglib

 Description   

The Facelet taglib XML file has a number of limitations and it might be a good idea to improve the format.

Currently when a component inherits from another component, each and every attribute of the parent component has to be copied into the tag declaration in the taglib file. This makes taglib files very verbose and makes it hard to see which attribute the new tag introduces. A solution to this would be adding a way to declare that a tag inherits from another tag.

For instance:

<tag extends-namespace="http://java.sun.com/jsf/html" extends-tag="form">
    <tag-name>form</tag-name>
    <component>
        <component-type>org.example.Form</component-type>
    </component>

    <attribute>
        <description>
            Whether to include all URL (GET) request parameters in the action URI.
        </description>
        <name>includeRequestParams</name>
        <required>false</required>
        <type>boolean</type>
    </attribute>

    <!-- 20+ attributes of h:form such as "render", "accept", etc inherited -->
</tag>

Components in JSF can introduce an (EL) variable for their children to consume, e.g. like the var attribute of a datatable. This can however not be declared in a taglib, so tools have to have hardcoded knowledge of which tag does what with which attribute. This means tools lack behind new tags from a certain component library and only well known component libraries are supported. It would be great if it could be declared that an attribute represents the name of an introduced (EL) variable.

For instance:

<attribute>
    <description>
        Name of a request-scope attribute under which the model data for the
        row selected by the current value of the "rowIndex" property
        (i.e. also the current value of the "rowData" property) will be exposed.
    </description>
    <name>var</name>
    <required>false</required>
    <type>java.lang.String</type>
    <output>
        <scope>request</scope>
        <type-ref-attribute>value</type-ref-attribute>
        <type-ref-collection-element>true</type-ref-collection-element>
    </output>
</attribute>

In the above example var is declared to be an "output variable", that has as its type the type of the "collection element" that's bound to the value attribute. E.g. if value is bound to a List<Foo>, then the type of var is Foo. Other options would be setting a fixed type or referring directly to the type of another attribute.

Another issue is that attributes often have a default and an allowed range of values. This now has to be communicated in the description of an attribute and that description has to be kept in sync with the actual code. Tools sometimes have hardcoded knowledge of the allowed values (for auto-completion and warning flagging) for some attribute, but this too can be out of sync with newer releases of a component lib and doesn't support lesser known or internal components.

It would help a lot of this could be declared in a taglib file as well. E.g.:

<attribute>
    <description>The ordering type.</description>
    <name>type</name>
    <required>false</required>
    <type>java.lang.String</type>
    <allowed-values>lt, lte, gt, gte</allowed-values>
    <default>lt</default>
</attribute>

Some JSF components, like e.g. datatable support multiple types for a given attribute. It might be an improvement if these types could be enumerated in the attribute's declaration, e.g.

<attribute>
    <description>
        The current value of this component.
    </description>
    <name>value</name>
    <required>false</required>
    <types>
        <type>javax.faces.model.DataModel</type>
        <type>java.util.List</type>
        <type>java.lang.Object[]</type>
        <type>java.sql.ResultSet</type>
        <type>javax.servlet.jsp.jstl.sql.Result</type>
        <type>java.util.Collection</type>
        <type>java.lang.Object </type>
    <types>
</attribute>

I'm sure there might be some other areas where taglib files can be improved besides the use cases mentioned above.



 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-1153] Make SelectItemsIterator public API Created: 03/Jan/13  Updated: 01/Aug/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: Minor
Reporter: Mathias Werlitz Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Make javax.faces.component.SelectItemsIterator public API since finding out the select items of a component is very complicated and this spec class already provides the required functionality.



 Comments   
Comment by Mathias Werlitz [ 03/Jan/13 ]

Unfortunately the class is currently package private and cannot be used in own components/converters etc. dealing with select items.

Comment by arjan tijms [ 19/May/13 ]

This would indeed be convenient. More than a few component libraries have reinvented the wheel for this (e.g. I created a version for OmniFaces).

Although the algorithm to collect/iterate over select items is specified, there's a small window for bugs if the component libraries use a (slightly) different version than the one the JSF implementation on which it runs is using.

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-1150] Add @ClientWindowScoped Created: 04/Dec/12  Updated: 24/Oct/16

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

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


 Description   

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



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

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

Comment by frederickkaempfer [ 05/Oct/15 ]

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

Comment by muellermi [ 23/Oct/16 ]

A corresponding CDI scope would be great. But, how can we ensure that a user does not transfer a client window id from one tab to the other by copy and pasting the URL?

Comment by lu4242 [ 24/Oct/16 ]

There is no perfect solution for that one. For historical purposes about the browser tab problem see https://struberg.wordpress.com/2011/11/13/solving-the-browser-tab-problem/ . Right now @FlowScoped relies on client window id. MyFaces has a client window mode different from the default that uses the url called "client", extracted from MyFaces CODI.





Restore ViewScope before templates are processed with buildView (JAVASERVERFACES_SPEC_PUBLIC-787)

[JAVASERVERFACES_SPEC_PUBLIC-1034] disentangle ViewScope state handling from UIViewRoot.saveState()/restoreState() methods to better control ViewScope state handling Created: 16/Aug/11  Updated: 12/Aug/14

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

Type: Sub-task Priority: Minor
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1087 CDI portable extension for @ViewScoped Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-787 Restore ViewScope before templates ar... Closed

 Description   

With JAVASERVERFACES_SPEC_PUBLIC-787 a new method restoreViewScopeState was added to UIViewRoot to allow restore ViewScope before buildView is called. But there is no matching saveViewScopeState method.

This issue proposes adding also a method saveViewScopeState() method to UIViewRoot and save the ViewScope state no longer as part of UIViewRoot's state array but rather as an element of the rawState Object[]. Looking at StateManagementStrategyImpl.saveView() - that always returns new Object[]

{ null, stateMap }

; I see element[0] is used to store component structure (full state saving only?). So an additional third element could keep the ViewScope state built from saveViewscopeState() - and restoreState would use thrid rawState element as argument to restoreViewScopeState().

That would allow more flexibility e.g if some impl. or adapter/bridge needs to handle ViewScope state differently. By wrapping UIViewRoot and overriding save-/restoreViewScopeState() methods that would be possible. Currently ViewScope state is bound to UIViewRoot state structure.



 Comments   
Comment by Darious3 [ 18/Aug/12 ]

Would this also help the much needed CDI implementation of @ViewScoped?

Comment by Hanspeter Duennenberger [ 03/Sep/12 ]

Could be, if CDI needs to support @ViewScoped, there must be a way to hook into view-scope state saving and restoring. By explicitly define when and how ViewScope state is saved and restored this would also allow other DI frameworks to provide the @ViewScoped beans. But then I think this will be a spec change and I guess it will not make it into 2.2.

Comment by Ed Burns [ 04/Sep/12 ]

You are right that we need to de-couple the implementation of @ViewScoped on top of CDI from code in UIViewRoot. More API needs to be done.

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-954] Standard validators should support a custom validation error messages Created: 01/Apr/11  Updated: 12/Aug/14

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

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

Status Whiteboard:

size_small importance_large


 Description   

UIInput components already support overriding validation messages with a field specific message and it is possible to override the default JSF validation messages globally. A common business requirement is to create individual error messages for very field and validation error type. The already available options do not allow field individual messages for different validators.

The spec should add a ValueExpression attribute "message" to all standard validators that is used in precedence of the standard message of each validator. This message may also contain the standard placeholders.

This is easy to implement and makes the standard validators much more flexible.
Example usage:

<h:inputText>
<f:validateRegex pattern="some pattern" message="The entered value is not a valid zip code." />
</h:inputText>



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

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

Comment by Ed Burns [ 01/Aug/14 ]

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





[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-761] Submitting forms destroys bookmarkable URLs on re-render or validation failure. Created: 05/Mar/10  Updated: 01/Aug/14

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

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

Operating System: Linux
Platform: PC


Issuezilla Id: 761
Status Whiteboard:

size_large importance_large


 Description   

<h:form> calls ViewHandler.getActionURL() in order to resolve the <form
action="..."> attribute.

The problem here is that when a page is accessed via a bookmarkable URL, the
form action does not use that bookmarkable URL for postbacks. This means that as
soon as a form is submitted, the page query-parameters are lost, meaning that
the resource (while it may still be functionally equivalent) is no longer
capable of bookmarking.

The argument "you shouldn't bookmark after a form submit:"

Bookmarking after a form submit should be just as valid as bookmarking that
resource the first time the page was accessed via GET-based navigation.

This loss of bookmarkability occurs when a form is submitted, validation fails,
or the page is re-rendered without re-directing and including page params
through a faces-config.xml complex navigation case.

A simple use-case to show the behavior: /faces/index.xhtml

<?xml version='1.0' encoding='UTF-8' ?>
<!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://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core">

<f:metadata>
<f:viewParam name="foo" value="#

{bar}" />
</f:metadata>

<h:link outcome="index.xhtml" value="go to bookmarkable URL" >
<f:param name="foo" value="bar" />
</h:link>

<h:form>
<h1>#{bar}

</h1>
<h:commandButton value="destroy bookmarkable URL"
action="?include-page-params=true" />
</h:form>
</html>

My proposed solution for this issue is to require that forms either:

A. re-render the URL of the page with which it was accessed.
B. require that forms call ViewHandler.getBookmarkableURL() instead of
ViewHandler.getActionURL(), and also require that any page parameter supplied
during the initial request, be preserved.



 Comments   
Comment by lincolnbaxter [ 24/Mar/10 ]

Use Case: Imagine a simple search form with dropdown filters. Publicly
accessible, but server-side state saving is enabled for security reasons.

  • visit yoursite.com/search (which is a JSF search form)
  • do a search
  • see results screen which itself has a populated search box
  • wait for session timeout
  • click search
  • blammo

or even simpler:

  • visit yoursite.com/search (which is a JSF search form)
  • wait for session timeout
  • click search
  • blammo

Due to the fact that the JSF form is rendered and always does a POST back, there
is no way to prevent this aside from the typical "refresh the page every few
minutes before session times out," which I do not consider a great solution
because it means you're keeping sessions open as long as people sit on that page.

If <h:form> supported the method="GET" attribute and behavior, people could
avoid this situation entirely. Basically turning the form into a way to bind and
validate input (no value change listeners, most likely) but still get
functionality of inputs and action methods. It would nicely address this kind of
simple use case.

Comment by lincolnbaxter [ 24/Mar/10 ]

Sorry – somehow I thought I was submitting a new issue..... ignore my last comment.

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 25/Jun/10 ]

triage

Comment by Ed Burns [ 06/Jul/10 ]

Roger, which GlassFIsh 3.1 milestone for this?

Comment by rogerk [ 06/Jul/10 ]

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 Darious3 [ 26/Oct/12 ]

OmniFaces has implemented a solution for this. See http://showcase-omnifaces.rhcloud.com/showcase/components/form.xhtml

It uses encodeBookMarkeableURL, but doesn't include any GET parameters that aren't also view parameters: http://code.google.com/p/omnifaces/source/browse/src/org/omnifaces/component/input/Form.java?name=1.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-609] ui:repeat varStatus incompletely specified. Created: 12/Aug/09  Updated: 01/Aug/14

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 609
Status Whiteboard:

cat2 vdldoc size_small importance_small


 Description   

The varStatus attribute on ui:repeat supports some of the concepts present in JSTL's LoopTagStatus [1],
including the "begin" and "end" concept. However, the corresponding attributes from c:forEach are not
exposed on ui:repeat. This issue would like to fix that.

[1] http://java.sun.com/javaee/6/docs/api/javax/servlet/jsp/jstl/core/LoopTagStatus.html



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

Taking the documentatation from c:forEach [1]

begin If items specified: Iteration begins at the item located at the specified index. First item of the
collection has index 0. If items not specified: Iteration begins with index set at the value specified.

end

If items specified: Iteration ends at the item located at the specified index (inclusive). If items not
specified: Iteration ends when index reaches the value specified.

[1] http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/c/forEach.html

Comment by Ed Burns [ 12/Aug/09 ]

Target to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

vdl

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-478] rendered attribute is overloaded Created: 02/Oct/08  Updated: 12/Aug/14

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

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

EGTop5 cat2 javadoc size_medium importance_large draft


 Description   

The rendered attribute is used to control whether a widget is rendered on the
page as well as whether it should be included in processing the postback. This
in itself is not a problem (except that the word rendered is misleading to
users), however the value of rendered is revaluated when the form is submitted,
and this value is used to decide whether to process the component.

Unfortunately, there is no easy way around this, especially if we move towards a
more stateless lifecycle. This may be a simple matter of better educating users.



 Comments   
Comment by pmuir [ 10/Oct/08 ]

A JBoss top priority issue issue

Comment by Ed Burns [ 15/Oct/08 ]

Change target milestone to 2.0

Comment by Ed Burns [ 24/Sep/09 ]

This is important for 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

javadoc

Comment by Ed Burns [ 22/Mar/10 ]

rendered

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

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

Worth considering so leave as is.





[JAVASERVERFACES_SPEC_PUBLIC-475] Run converters even if value to convert is null Created: 02/Oct/08  Updated: 21/Feb/16

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

Type: Improvement Priority: Minor
Reporter: pmuir 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


Issue Links:
Related
is related to JAVASERVERFACES-630 Allow nulls to be passed to converters Closed
Issuezilla Id: 475
Status Whiteboard:

EGEasy5 cat2 size_medium importance_large


 Description   

The spec doesn't require converters to be run, even if the value to be converted
is null (and the RI doesn't run converters in this case). This is a weird omission.



 Comments   
Comment by pmuir [ 10/Oct/08 ]

A JBoss top priority issue issue

Comment by Ed Burns [ 15/Oct/08 ]

Change target milestone to 2.0

Comment by Ed Burns [ 03/Sep/09 ]

2.1

Comment by kito75 [ 14/Oct/09 ]

Didn't we handle this in 2.0?

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

Comment by Ed Burns [ 27/Apr/10 ]

not a signature change.

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 ]

sheetalv

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-470] javax.faces.convert.EnumConverter - defective by design? Created: 12/Sep/08  Updated: 12/Aug/14

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

Type: Bug Priority: Minor
Reporter: kennardconsulting 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
URL: http://forums.sun.com/thread.jspa?threadID=5330940


Issuezilla Id: 470
Status Whiteboard:

EGEasy5 cat2 javadoc size_large importance_medium


 Description   

I'm confused as to how javax.faces.convert.EnumConverter is ever supposed to
work. It basically does:

getAsString: value.toString();
getAsObject: Enum.valueOf( targetClass, value );

But Enum.valueOf was never designed to be the opposite of value.toString(). The
JavaDoc says it is the opposite of value.name(). So if you ever override an
enum value to have a different toString than its name (a common occurence)...

enum Gender {
MALE {
public String toString()

{ return "Male"; }

}

...then EnumConverter won't work for you. Surely this is a bug in the spec?

For a long time now I've been using my own EnumConverter with JSF 1.1. It
does...

getAsString: if ( component instanceof UIInput ) return value.name() else
value.toString();
getAsObject: Enum.valueOf( targetClass, value );

...so there's a caveat when you're using labels (when you really do want
the .toString() instead of the .name() to appear), but for UIInputs (eg.
UISelects) you need to use the name() or it will never convert back.

Can this design decision be double checked for JSF 2.0?

Thanks,

Richard.



 Comments   
Comment by pmuir [ 23/Sep/08 ]

Add to EGEasy5, this bug is correct, and a one line change.

Comment by Ed Burns [ 23/Sep/08 ]

target 2.0

Comment by kennardconsulting [ 23/Sep/08 ]

Awesome. Thanks guys.

Comment by Ed Burns [ 10/Aug/09 ]

I think this is fixed. Imre appears to have fixed it.

Comment by Ed Burns [ 10/Aug/09 ]

r6792 | edburns | 2009-03-11 17:14:23 -0400 (Wed, 11 Mar 2009) | 12 lines

Issue: EnumConverter.getAsString()

Author: Imre Osswald

r=edburns

SECTION: Modified Files
----------------------------
M jsf-api/src/javax/faces/convert/EnumConverter.java

  • use the name() instead of toString() on the enum.
Comment by kennardconsulting [ 10/Aug/09 ]

Thanks for looking at this, however please reopen this issue.

The fix by Imre changes .name() to .toString(), which is correct for UIInputs
but will make JSF worse for all UIOutputs (ie. labels). If you have an enum...

enum Gender {
MALE {
String toString()

{ return "Male"; }

}
}

...and...

<h:outputText value="#

{gender}

"/>

...then JSF 1.x will display...

Male

...which is what you want. JSF 1.x only breaks if you are using UIInputs (like
UISelect), but please don't affect the UIOutputText case. With Imre's changes,
everybody's labels are going to display...

MALE

...which is undesirable, not to mention incompatible, behaviour.

I mentioned this in the 'caveat' when I originally opened this bug.

Regards,

Richard.

Comment by Ed Burns [ 10/Aug/09 ]

Imre and I chatted on IRC and agree with Richard. Thanks for staying on this Richard.

Comment by kennardconsulting [ 10/Aug/09 ]

No worries. Thank YOU for listening

Comment by Ed Burns [ 24/Sep/09 ]

Move to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by Ed Burns [ 24/Feb/10 ]

Agree

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 15/Mar/10 ]

converter

Comment by Ed Burns [ 19/Mar/10 ]

> EnumConverter uses toString() instead of name()
> -----------------------------------------------
>
> Key: MYFACES-2614
> URL: https://issues.apache.org/jira/browse/MYFACES-2614
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 1.2.8, 2.0.0-beta-3
> Reporter: gui
> Assignee: Jakob Korherr
> Fix For: 1.2.9-SNAPSHOT, 2.0.0-beta-3
>
>
> Hi,
> I have an enum that has overridden the toString method.
> It seems the EnumConverter uses toString to convert an enum to a string (and
Enum.valueOf(..) to find it back). However, since my toString is overriden, the
value it returns is not valid input for the Enum.valueOf(..) function and the
converter raises an exception.
> A better approach is to use .name() as string representation of an Enum.

Comment by Ed Burns [ 10/May/10</