• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Manual refresh issue

 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys ,

I need your help .

i am developing a simple project with jsf2.0 and primefaces 3.2.

I have 2 pages first is the page1.xhtml whci contains :



When i press The command link it forwarded me to another page which have a selectOneMenu which doesn't show its items until i refresh the page manually .


 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).
 
khaled hanafy
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Thanks again
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
I'd appreciate it if you pronounced my name correctly. Pinhead, with a silent "H". Petite ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic