This week's book giveaways are in the iOS and Features new in Java 8 forums. We're giving away four copies each of Barcodes with iOS: Bringing together the digital and physical worlds and Core Java for the Impatient and have the authors on-line! See this thread and this one for details.
The SelectOneMenu items that display are going to be whatever was returned from bussinessOwnersViewerMB.getCities() at the time the new page was requested.
I do not recommend passing the information needed to construct that list in by using parameters on the commandLink.
In fact, I almost never put parameters on the commandLink.
A more JSF-centric approach would be to inject bussinessOwnersViewerMB into the "ct" backing bean. Do not use a View ID as the "action" value in the commandButton, reference an action Method in the "ct" backing bean. That action method would then initialize bussinessOwnersViewerMB and direct JSF to navigate to "distributer/distributersList.xhtml". Or, more appropriately: "/distributer/distributersList".
While the ct action method can do any configuration to bussinessOwnersViewerMB that it wishes, I usually have code in bussinessOwnersViewerMB to do most of the initialization so that code doesn't get scattered over many different objects (which is one of the reasons I don't parameterize commandLinks).
So in bussinessOwnersViewerMB, I typically would have a "beginList()" method that the "ct" bean could invoke. In cases where I need to supply a parameter to select, for example, a business to edit, I'd pass that parameter to beginList() instead of using a parameter on the commandLInk itself.
Please note, however, that when you inject a bean like bussinessOwnersViewerMB into another bean such as "ct", that bussinessOwnersViewerMB must have a scope that allows it to be accessed properly. That usually means session scope, since View Scope would destroy the bean you injected into the first page (view) and create a new, uninitialized bean for the second page (view).
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Jun 28, 2010
Thanks alot Tim Holloway for your fast and helpful reply .
I need more clarification ..
Is it not good practice to call the page immediately from the action attribute of the commandButton ?
and from your reply i understanded that the problem in the forwarding the request and i should redirect it and set the request parameter through the managed bean instance which i should make it in the session scope.
It is not a good practice to have one page (View) "call" another page (View) directly in JSF. JSF is designed with the idea of being able to employ reusable components, and if you have to make components aware of specific other components, then they become less reusable. For this same reason, the backing beans are POJOs wired together externally using Inversion of Control.
Beyond that, the Model/View/Controller architecture is based on a separation of concerns. Under that strategy, no business-related logic should ever be located on View templates. Again, because it couples components together too tightly, but also because in practical terms, when you need to update logic, you no longer have a "one-stop solution" - you have to on a "treasure hunt" to find where things are being done, since they may be on the view or they may be done on the backing bean or they may be an unholy mish-mash of both. So isolation of the logic to just the backing bean is much more economical.
Finally, above and beyond all that, the more data you post out and read back, the more network overhead, and the less security you have. JSF's preferred paradigm is to keep all those sordid details out of sight on the server, where they don't have to clutter up the network traffic and they cannot be hacked by hostile clients.
That isn't to say that I never put page links directly on my View definitions. It is not uncommon for me to do things like have a button whose action is simply "/Home", meaning discard all current work and navigate immediately to the "Home.jsf" URL. But it's not all that common, either, since I can rarely just drop everything when I cancel an operation - I often need to do cleanup in the backing bean first.