[JAVASERVERFACES_SPEC_PUBLIC-1358] Enhance conversation handling Created: 02/Feb/15  Updated: 03/Feb/15

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

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


 Description   

During a process flow, using @ConversationScoped beans, sometime it is useful to start a new (second, third, ...) conversation.
Using the standard postback navigation, JSF always injects the same conversation instance.
One approach to force a fresh conversation is to use <h:link ...> instead of <h:commandLink...>
Since the outcome of link is computed whilst rendering the page, navigation is static.
commandLink on the other hand allows to compute the navigation on click.
I propose these enhancements:

<h:commandLink createConversation="true" ...>

With this optional argument JSF does not inject the existing instance of a session but a fresh one.

<h:link output="#{...}" lazyCalculation="true" ...>

This renders a link without target <a href="" onclick="#{bean.navigationFunction}">...</a> and an onclick handler.
The handler's duty is to perform a partial request, retrieve the result of bean.navigationFunction (return value is String) and then perform a get navigation, e.g. by window.location.href = navOutcome;






[JAVASERVERFACES_SPEC_PUBLIC-1040] Outstanding PhaseListener.afterPhase() calls for the current phase should be made before any requested redirect actually takes place Created: 19/Oct/11  Updated: 12/Aug/14

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

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


 Description   

See email thread beginning at http://java.net/projects/javaserverfaces/lists/dev/archive/2011-10/message/5 .



 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-937] Disable implicit navigation for JSF 1.x applications Created: 31/Jan/11  Updated: 01/Aug/14

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

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

Status Whiteboard:

size_small importance_medium


 Description   

Currently, implicit navigation seems to be enabled for all applications that
are deployed on a container with Mojarra 2.0, even when they have a JSF 1.x
configuration. Because some of the action methods in our 1.x applications can
return an outcome that isn't defined in the navigation rules in faces-
new view (one that possibly doesn't even exist) instead of doing nothing, like
Mojarra 1.2 did.

It would be great for maintaining compatibility with 1.x applications if
implicit navigation is disabled when a 1.x configuration is found. Adding a
context initialization parameter to explicitly disable implicit navigation
could also be useful.
Description
Currently, implicit navigation seems to be enabled for all applications that are deployed on a container with Mojarra 2.0, even when they have a JSF 1.x configuration. Because some of the action methods in our 1.x applications can return an outcome that isn't defined in the navigation rules in faces- new view (one that possibly doesn't even exist) instead of doing nothing, like Mojarra 1.2 did. It would be great for maintaining compatibility with 1.x applications if implicit navigation is disabled when a 1.x configuration is found. Adding a context initialization parameter to explicitly disable implicit navigation could also be useful.



 Comments   
Comment by rogerk [ 31/Jan/11 ]

Additional comments from http://java.net/jira/secure/ViewProfile.jspa?name=omolenkamp

Ok, Bugzilla / some javascript / my browser somehow strips a line starting at
config dot xml. Last attempt:

"Because some of the action methods in our 1.x applications can
return an outcome that isn't defined in the navigation rules in faces dash
config dot xml, Mojarra 2.0 will in such a case redirect to a new view (one
that possibly doesn't even exist) instead of doing nothing, like
Mojarra 1.2 did."

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-1180] Do not include empty view params using `includeViewParams=true` Created: 07/Apr/13  Updated: 13/Aug/14

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

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

Glassfish 3.12


Tags: includeviewparams, navigation

 Description   

Having a command component with an action attribute and using 'includeViewParams=true' using Navigation will include all view parameters defined in `f:metadata`.

But empty parameters are passed as String representations creating ugly url's.

'site.xhtml?key1=value1&key2=&key3='



 Comments   
Comment by djmj [ 27/Apr/13 ]

In my Converter's I return now null instead of empty String. Since it seems null value's won't be included.

But this leads to other issue: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1187

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-1175] Validation error removes all url parameters Created: 18/Mar/13  Updated: 01/Aug/14

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

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


 Description   

This bug was copied from Mojarra issue tracker. See details here:
http://java.net/jira/browse/JAVASERVERFACES-1653

When page has some url parameter(s) after server-side validation error or by
default navigation JSF navigates to the page with the same viewId but without
url parameters.

IMHO the problem is the POST method submits the form to viewId's url only
instead of using url with the parameters as original url has.

This issue makes problems with bookmarking such views with params after handling
some action(minor problem) and generating proper response after action handling
based on this parameters(major problem) .

P.S. Also this issue has another side effect. When handling some action the url
parameters are unavailable.

--------------------
I found some easy workaround for this problem.

I just slightly extend standard ViewHandler to add the queryString to the action
url:

public class UrlWorkaroundMultiViewHandler extends MultiViewHandler {

@Override
public String getActionURL(FacesContext context, String viewId) {

String result = super.getActionURL(context, viewId);
String queryString = ((HttpServletRequest) context.getExternalContext()
.getRequest()).getQueryString();
if (queryString != null)

{ result += "?" + queryString; }

return result;

}
}

and register it in the faces-config.xml

<application>

<view-handler>my.workaround.UrlWorkaroundMultiViewHandler</view-handler>
</application>

I'm not sure this will work for any cases and for all servlet containers. Also
I'm not sure about possible side effects.
I did check it with Jetty.

-----------------------------
UPDATE: I found that we have not add params when we handle new url. So I modify my workaround code to handle more cases:

@Override
public String getActionURL(FacesContext context, String viewId) {

String result = super.getActionURL(context, viewId);

HttpServletRequest request = ((HttpServletRequest) context
.getExternalContext().getRequest());

if (viewId.equals(request.getServletPath())) {
//Do it just if we are on the same page
String qs = request.getQueryString();
if (qs != null)

{ result += "?" + qs; }

}

return result;

}
===============================================
Conclusion: I believe that any valid url should be preserved as is(including query parameters). Even we do not use its url parmas on our page.



 Comments   
Comment by arjan tijms [ 20/Mar/13 ]

This looks like a duplicate of JAVASERVERFACES_SPEC_PUBLIC-1163.

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-870] Need a PreNavigate system event Created: 26/Jul/10  Updated: 12/Aug/14

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

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

Operating System: Linux
Platform: PC


Issuezilla Id: 870
Status Whiteboard:

size_medium importance_small


 Description   

In order to properly intercept and extend navigation, it would be helpful to
have a PreNavigateEvent that included the current target navigation case (as
returned by:

public abstract NavigationCase getNavigationCase(FacesContext context, String
fromAction, String outcome);

public class PreNavigateEvent extends SystemEvent
{
public NavigationCase getNavigationCase()

{...}

}



 Comments   
Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-769] Add read-only "derived" property to NavigationCase Created: 17/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: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 769
Status Whiteboard:

cat2 javadoc frame size_small importance_medium


 Description   

I think Dan is talking about the NavigationCase Java language artifact.

DA> The problem is, there is no way to know whether that NavigationCase
DA> was sourced from a real navigation case or derived using implicit
DA> navigation. So what I am looking for is the following API addition:

DA> NavigationCase#isDerived()

DA> I suggest "derived" over "implicit" because it leaves room for any
DA> sort of dynamic creation...perhaps implicit isn't the only option.

I like that. I'll look into how implementable it is.



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

2.1

Comment by Ed Burns [ 17/Mar/10 ]
      • Issue 736 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 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 ]

Set 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





Generated at Thu Mar 05 15:34:05 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.