I have a .xhtml model with a primeface datatable in it.
I call the page with an URL like this:
http://localhost:8080/myproject/mypage.jsf?Id=51&startDate=04-05-2015&name=whatever
The URL parameters are used to retrieve what will be displayed in the datatable, so it allow me to filter the content.
I used URL parameter because this page is displayed when I select a row in another datable so I have to make a manual redirect to this page on the baking bean.
However everytime I use one of primeface functionality like sorting or pagination primeface seems to do an ajax call to the backing bean but WITHOUT the parameters, so every object are displayed instead of a filtered list of Objects.
Therefore how can I force primefaces to use these parameters? Or how can I pass them to primefaces scope (they are #ManagedProperty on the backing bean)
The best and easiest way is to use the OmniFaces utility library and more specifically their <o:form>.
From the documentation:
The <o:form> is a component that extends the standard <h:form> and provides a way to keep view or request parameters in the request URL after a post-back
...
You can use it the same way as <h:form>, you only need to change h: to o:.
So, replace your <h:form> by either
<o:form includeRequestParams="true">
or
<o:form useRequestURI="true">
See also:
Retaining GET request query string parameters on JSF form submit
Related
I would like to know is there any way to hide/show links to certain pages by using the rendered jsf tag in conjunction with a bean method.
for eg. rendered="#{sidebarController.isGrantedAcess("Admin")} doesn't work
When should I use an <h:outputLink> instead of an <h:commandLink>?
I understand that a commandLink generates an HTTP post; I'm guessing that outputLink will generate HTTP gets. That said, most of the JSF tutorial material I've read uses commandLink (almost?) exclusively.
Context: I am implementing a wee little demo project that shows a header link to a user page, much like Stack Overflow's...
...and I am not sure if commandLink (perhaps using ?faces-redirect=true for bookmarkability) or outputLink is the right choice.
The <h:outputLink> renders a fullworthy HTML <a> element with the proper URL in the href attribute which fires a bookmarkable GET request. It cannot directly invoke a managed bean action method.
<h:outputLink value="destination.xhtml">link text</h:outputLink>
The <h:commandLink> renders a HTML <a> element with an onclick script which submits a (hidden) POST form and can invoke a managed bean action method. It's also required to be placed inside a <h:form>.
<h:form>
<h:commandLink value="link text" action="destination" />
</h:form>
The ?faces-redirect=true parameter on the <h:commandLink>, which triggers a redirect after the POST (as per the Post-Redirect-Get pattern), only improves bookmarkability of the target page when the link is actually clicked (the URL won't be "one behind" anymore), but it doesn't change the href of the <a> element to be a fullworthy URL. It still remains #.
<h:form>
<h:commandLink value="link text" action="destination?faces-redirect=true" />
</h:form>
Since JSF 2.0, there's also the <h:link> which can take a view ID (a navigation case outcome) instead of an URL. It will generate a HTML <a> element as well with the proper URL in href.
<h:link value="link text" outcome="destination" />
So, if it's for pure and bookmarkable page-to-page navigation like the SO username link, then use <h:outputLink> or <h:link>. That's also better for SEO since bots usually doesn't cipher POST forms nor JS code. Also, UX will be improved as the pages are now bookmarkable and the URL is not "one behind" anymore.
When necessary, you can do the preprocessing job in the constructor or #PostConstruct of a #RequestScoped or #ViewScoped #ManagedBean which is attached to the destination page in question. You can make use of #ManagedProperty or <f:viewParam> to set GET parameters as bean properties.
See also:
ViewParam vs #ManagedProperty(value = "#{param.id}")
What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?
Bookmarkability via View Parameters feature
How to navigate in JSF? How to make URL reflect current page (and not previous one)
I also see that the page loading (performance) takes a long time on using h:commandLink than h:link. h:link is faster compared to h:commandLink
I have a Primefaces commandLink which I have used it many times in my application. Now I want to store it's URL in a bundle.property file to make it maintainable. which xhtml attribute should I use to redirect it?
I already tried things like:
actionListener="#{bundle.Myurl}"
action="#{bundle.Myurl}"
target="#{bundle.Myurl}"
Myurl also contains this: sales/index.xhtml
but none of them run as I want!
You shouldn't use command links for page-to-page navigation in first place. Use a normal link.
If you have an internal URL / (implicit) navigation outcome:
<h:link value="link" outcome="#{bundle.Myurl}" />
Or if you have an external URL:
<h:outputLink value="#{bundle.Myurl}">link</h:outputLink>
Your attempts failed because the actionListener and action attributes are declared as MethodExpression attributes, meaning that any EL will be interpreted as a bean action method. The target attribute has an entirely different meaning, which is exactly the same as the generated HTML <a> element has.
See also:
When should I use h:outputLink instead of h:commandLink?
When i use
<h:button>
or
<h:link>
i can't make any business action in managed bean ?
Do I have to use
<h:form>
and
<h:commandButton>
or
<h:commandLink>
with action param or there is another solution ?
Depends on the kind of request you'd like to fire.
If it needs to be a non-idempotent POST request, just use <h:form> with <h:commandXxx action>. Again depending on the concrete functional requirement, you can render the results conditionally in the same view, or send a redirect to the target view afterwards.
If it needs to be an idempotent GET request, use <h:link>/<h:button> and perform the action in #PostConstruct method in the request/view scoped backing bean associated with the target page. If you need to pass parameters, use <f:param> to set them on <h:link>/<h:button> and use <f:viewParam> and <f:event type="preRenderView"> in target view to set and process them in backing bean associated with target view.
All in all, just use the right tool for the job as specified by concrete functional requirement (which you unfortunately didn't tell anything about in your question).
See also:
How to navigate in JSF? How to make URL reflect current page (and not previous one)
What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?
Communication in JSF 2.0
No, you can't do that with h:link or h:button, there are meant to be bookmarkable GET urls. So if you want to perform business action, you need to use either commandButton or commandLink. Note that it's also worth to use h:outputLink for generating bookmarkable links between pages because is much more SEO friendly.
I searched everywhere but could not find a solution to this. I am trying to used
required=yes to validate whether a value is present or not. I am using it inside inputtext.
The problem is it does not work inside a datatable. If I put the text box outside the datatable it works. I am using JSF 1.7 so I don't have the validateRequired tag from JSF 2.0.
I even used a validator class but it is still not working. Does anyone know why does required=yes or validator='validationClass' inside a inputtext inside a datatable is not working.
I appreciate the help.
Thanks.
First of all, the proper attribute values of the required attribute are the boolean values true or false, not a string value of Yes. It's an attribute which accepts a boolean expression.
The following are proper usage examples:
<h:inputText required="true" />
<h:inputText required="#{bean.booleanValue}" />
<h:inputText required="#{bean.stringValue == 'Yes'}" />
As to the problem that it doesn't work inside a <h:dataTable>, that can happen when the datamodel is not been preserved properly (the datamodel is whatever the table retrieves in its value attribute). That can in turn happen when the managed bean is request scoped and doesn't prepare the datamodel during its (post)construction which causes that the datamodel is null or empty while JSF is about to gather, convert and validate the submitted values.
You need to ensure that the datamodel is exactly the same during the apply request values phase of the form submit request as it was during the render response phase of the initial request to display the form with the table. An easy quick test is to put the bean in the session scope. If that fixes the problem, then you definitely need to rewrite the datamodel preserving logic. You could also use Tomahawk's <t:saveState> or <t:dataTable preserveDataModel="true"> to store the datamodel in the view scope (like as JSF2's new view scope is doing).
Finally, JSF 1.7 doesn't exist. Perhaps you mean JSF 1.2?