You can fire a tequest to a url from your JS function. There are some points ...
1. If your present page is test.faces then submit to the same url, ie. /root_path/.../test.faces 2. JSF uses some hidden fields to keep track from which view the request is coming from and uses this to decide the next navigation. You need to read these hidden fields and other form item parameters to the request url.
OK, let's make one thing perfectly clear. a JSF web application runs via HTTP. HTTP is a Request/Response protocol. A server cannot initiate actions nor can server applications. They can only react to requests. No request, no response. So something has to "click the button", even for AJAX apps. All AJAX is is an HTTP request embedded within a displayed page.
So, to remove any doubt: ANY JSF code running in a backing bean is doing so because someone made a request. That request may or may not have included an action request, but it was a request nevertheless. An since there's no particular penalty for action requests, you might as well use an action request anyway.
Now whether or not you use a "button" object is somewhat optional - JSF has 2 core action elements: commandLink and commandButton. The commandLink element renders as a hyperlink and the commandButton renders as a pushbutton. Unless, of course, you get creative with CSS, in which case it's largely up to you what it's going to look like.
I'd say that the #1 problem people have designing webapps is in understanding that they're not full-bore client/server systems, and it doesn't help that people carelessly throw around the term "MVC". True MVC is impossible over HTTP, since it requires the controller to be able to asynchronously post model updates to the client, and HTTP can only update when it's responding to requests.
Struts made the distinction by using the term "Model 2" architecture, but JSF usually just calls it MVC. And to make things worse, JSF is about as close to true MVC as HTTP can get, so that just makes it more confusing.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Well he must already be in server side code because he says
My problem is - I want to launch navigation at a point from a function with void return type
So since he is in a function with a void return type, must be in action listener ot value change listener or something (perhaps with immediate property)...These will make function call to server side code with void return value, unlike action methods which return a String indicating where to navigate to (in the standard fashion).
Here is real tested code that reacts to a value change listener on a checkbox with immediate property and successfully navigates to a new page:
So we have navigation from a function with a void return parameter reacting to a checkbox changing.
The only thing that kept the leeches off of me was this tiny ad:
a bit of art, as a gift, that will fit in a stocking