Navigation rule "pretty:" does not update URL

[GoogleCodeExporter]

Hi Lincoln,

as discussed on JSF days in Vienna, here is the issue:
When you are using the same JSF action method (e.g. for a command button)
on different pages and a bean value in the URL, it would be very handy to
have a navigation rule that redirects to the currently displayes page and
generate the URL with the new value.
If you're using "pretty:" for this purpose, it just refreshes the page and
not the URL. Therefore you have to make a distinction in the action method
code on which page you currently are and give back the belonging full
navigation string "pretty:id" of the current page. It would be more
convient if you would just have to return "pretty:"

Best regards
Markus

Original issue reported on code.google.com by markus.h...@gmail.com on 26 Feb 2010 at 7:18

[GoogleCodeExporter]

I'm a little worried about changing this -- it's possible that it could break
people's applications. But I still think there needs to be a way to do it.

"pretty:" might be the right answer -- not sure yet. Maybe a different keyword.

Original comment by lincolnb...@gmail.com on 29 Mar 2010 at 6:57

• Changed title: Navigation rule "pretty:" does not update URL
• Changed state: Accepted

[GoogleCodeExporter]

Markus -- It's been forever since you submitted this, but I think that this 
needs to
stay the way it is. 

you could do the following to get the behavior you want (which is all 
PrettyFaces
would be able to internally do if the behavior were changed.)

public String myActionMethod()
{
   return PrettyContext.getCurrentMapping().getId();
}

This lets you refresh the value of the page and update the URL parameters, but 
also
gives the option to use "pretty:" to refresh the page without updating URL 
parameters.

Is that an acceptable workaround? It's been a while since we talked about this, 
so I
may have forgotten something important.

Original comment by lincolnb...@gmail.com on 12 May 2010 at 9:31

• Changed state: Started

[GoogleCodeExporter]

I'm not sure why I didn't think of that workaround earlier, which makes me 
wonder if
I did indeed forget something. Changing to enhancement request.

Original comment by lincolnb...@gmail.com on 12 May 2010 at 9:31

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Hi Lincoln,
the workaround is very fine, I'm already using this.
Thx for your help.

Original comment by markus.h...@gmail.com on 15 May 2010 at 11:02

[GoogleCodeExporter]

Decided that since a viable workaround exists, this does not need to be changed,
since it provides a valuable functionality in itself.

Original comment by lincolnb...@gmail.com on 17 May 2010 at 4:31

• Changed state: WontFix