The scenario is like this. I have a rich:tabPanel with about 5 tabs. On first tab there is a rich:datatable. When I click on first column's element (a4j:commandLink), I get another rich:datatable. When I click on first column's element (a4j:commandLink) of this table, I change the tab where I have another rich:datatable and the same thing follows as above. The constraints from previous tab is used to get elements for the current one. If I click on the tab directly I get all elements related to that tab. Each rich:datatable refers to different tables. Each table is interrelated. Each tab refers to a single managed bean. I am using hibernate in backend.
The problem starts now. I dont want the managed beans to be session or application based since there are many variables to store. If I give request scope, the following thing happens. The first table in the tab renders perfectly, however when I click on the first column, the second table doesn't use all constraints since the scope is request, for example actionlistener. What am I supposed to do ?
One thing I can do is define one managed bean for each table. Or forcefully use session scope. Or is there any other way? Please help.
Thanks.
If you are using Richfaces 3.0.0 or above you can annotate your bean with #KeepAlive
or use the tag <a4j:keepAlive beanName="#{bean}" /> instead.
This is an equivalent to the view scope in JSF 2.0.
If you're already on JSF 2.0, use view scope. It's a scope which lives as long as you're interacting with the same page (independently of the browser tab/session!).
If you're still on JSF 1.x, use request scope with an <a4j:keepAlive beanName="#{bean}" /> declared in the view. It behaves like the JSF 2.0 view scope.
Related
We're making usage of Primefaces Wizard component and the forms been included within the Wizard's TABs were declared inside some UI Fragments with their respective Managed Beans. Each one of the Managed Beans contains properties representing some Entities.
What we need to achieve is that, for every completed step, we take the above mentioned Entity property that was previously fulfilled and designate the same Entity property inside the Wizard Managed Bean, and later we may present the Entities data like a summary, so the user would decide whether to proceed or not.
I'm wondering whether there are some other options to accomplish that rather than set a Session variable across the Wizard navigation.
Is the JSF #ManagedProperty usage feasible?
Tks.
Is it possible to set current displayed tab programmatically in <p:wizard>?
For example, I want that for two different request to the same page which contains a wizard, to have a different tab selected.
What I am currently trying to do, is to have a wizard with many tabs, in the second tab I have a redirection to another page, so when I come back I want to come to the last step which caused the redirection.
Can you please help me ? Thank you a lot !
According to primefaces documentation there's a step attribute for p:wizard tag, which specifies the step of the wizard you're currently in.
attribute: step
default value: 0
type: String
description: Id of the current step in flow
You must bind this attribute to a value of your backing bean and maintain it during redirection and coming back. If your wizard's bean is #ViewScoped you'll loose that info during redirection step, so you have to pass it using a view param or flash scope.
My answer would most probably not meet your complete requirements, but, nonetheless, it may point you towards solution to your problem.
As far as I know, the PrimeFaces Wizard UIComponent is designed for a workflow of one page. That effectively means that inputs will be handled by a backing beans that is in a view scope.
This way, making a redirection on a certain step will clear all data inputs, because your view changes and the old one is destroyed.
Anyway, a means of setting a current tab for display is step attribute of Wizard component. So,
<p:wizard step="#{wizardBean.currentStep}" >...</p:wizard>
will force the wizard to show you step which you specified in your bean. You may be able to get it by using, for example, a view parameter, like in
<f:viewParam name="step" value="#{wizardBean.currentStep}" />
But it will make sense if lifetime of your bean is more that for a view, for example, the bean could be put in session scope.
That said, maybe it is a better idea to do login beforehand. Or, if it is absolutely necessary to do it in step 2 of your wizard, provide for a built-in login functionality in a page itself, or in a popular window?
Also, programmatically the setting you speak of can be achieved via a binding of component to your backing bean and setting the step value in the backing bean, for example, in a preRenderView event.
The scenario is the following:
A managed bean uses as attributes another managed bean, like customerBean.current.customerAgreement. When I display the data on a pge the expression #{customerBean.current.customerAgreement.agreementTitle} is filled and shows the expected output.
However in an inputText the value is only changed on the screen, not in the value I get back in the managedBean. Is there a limitation on how deep such a structure can be constructed?
No, there is basically no limitation in how deep you can nest beans.
Your problem is caused by something else. Perhaps you are not preserving the same parent beans in the request of the form submit as it was during the request of the form display. Hard to tell without further detail about your code. All what I can suggest is to try making CustomerBean a view scoped bean.
I'm loving the jsf 2.0 composite component setup. One other thing I love is prependId="false" on forms. Is there an equivalent that can be defined in cc:interface or cc:implementation that will prevent jsf from creating a j_id to prepend to the ids defined within the composite component?
That's not possible. Just give the component a fixed id instead letting JSF autogenerate one. The same applies on forms by the way. This way you can still select them using CSS selectors.
Or better, just give them a styleClass so that you don't need to select by ID, for the case that this aversion was actually caused by inability to select components/elements by client ID (I don't see other feasible reasons).
I have a managed bean called UserSearchHandler, it has a doSearch method that populates UserSearchHandler.searchResults which are displayed in a table on the userSearch.xhtml page.
I have another managed bean called UserHandler, it has a showUser method and so on.
In the search results table, the user name is a link that, when clicked, is supposed to show user details on a userView.xhtml page. The table and link looks like this:
<p:dataTable var="user" value="#{userSearchHandler.searchResults" >
// ... and so on ... then
<h:commandLink value="#{user.firstName}" action="#{userHandler.showUser}">
<f:setPropertyActionListener target="#{userHandler.userIdToShow}" value="#{profile.id}"/>
</h:commandLink>
Everything works fine when the managed beans are set to session scope.
However, when I change the scope on the beans to request, the search works and the table gets populated, but when I click on the name link nothing happens. I put a break point on the userHandler.showUser method and it never gets hit when the userSearchHandler is set to "request" scope.
Can anyone help explain why this is, or what I'm doing wrong?
That's because the #{userSearchHandler.searchResults} is empty during the new request and therefore JSF is unable to locate the associated row where the commandlink is been invoked in order invoke the action (and to pass/set properties if any).
You need to ensure that the same #{userSearchHandler.searchResults} is precreated during bean's construction/initialization. If it's to be created based on a specific set of parameters, then you've to pass them along with the form as well.
That's exactly the reason why solutions like Tomahawk's <t:saveState /> and new JSF 2.0 view scope exist.
See also:
What are the main disadvantages of JSF 2.0?
I have a couple of ideas. If you're using a in your navigation you can try taking that out. Doing so would mean the browser will not make a new HTTP request when it renders the second window. It is the new HTTP request which clears the request scoped beans by. If that is not an option, you may be able to pass a parameter in your link such as a record id, which could allow you to pull data from your data source matching that id.