I'm using an <f:viewParam> to pass a parameter as follows.
<ui:define name="metaData">
<f:metadata>
<f:viewParam name="id" value="#{bean.entity}" converter="#{converter}"/>
</f:metadata>
</ui:define>
Is it possible to process this <f:viewParam>, only when the page is loaded/refreshed?
It is just because the converter as specified with the <f:viewParam> is costly that converts the value passed through the query-string to a JPA entity. Hence, it involves an expensive database transaction, even when doing ajaxical postbacks using components like <p:commandButton>, <p:commandLink> which is unnecessary.
So, when for example, a <p:commandLink> (ajaxical) is clicked, the expensive business service (in the converter) should not be executed. Can this be done?
This somehow works (strange enough nevertheless), when the rendered attribute is evaluated against facesContext.postback like rendered="#{not facesContext.postback}" but the attribute rendered is not documented. Hence, it is unreliable.
You can achieve this by creating a custom tag extending <f:viewParam> wherein you store the submitted value as an instance variable which isn't stored in JSF view state instead of in the JSF view state as the <f:viewParam> by default does. By end of request, all UI component instances are destroyed. They are recreated in beginning of the request. When submitted value is null, then it won't call the converter nor the model setter. This all is elaborated in Arjan Tijms' blog.
OmniFaces offers already since version 1.0 a ready to use solution in flavor of <o:viewParam>, see also my own blog on that. Based on your question history, you're already using OmniFaces, so all you basically need to do is to replace f: by o:.
<ui:define name="metaData">
<f:metadata>
<o:viewParam name="id" value="#{bean.entity}" converter="#{converter}"/>
</f:metadata>
</ui:define>
This won't call the model setter (nor the converter) during postbacks on the same view.
This somehow works (strange enough nevertheless), when the rendered attribute is evaluated against facesContext.postback like rendered="#{not facesContext.postback}" but the attribute rendered is not documented. Hence, it is unreliable.
That's because the <f:viewParam> is in essence an UIInput component (else it wouldn't be able to perform conversion, validation, model-update and all that stuff like usual input components) which is thus just an UIComponent supporting a rendered attribute. This is however not explicitly documented as it actually doesn't render anything to the HTML output (that's also why it's a f:xxx, not a h:xxx). But with this attribute you can actually control the behavior during postback as this attribute is also evaluated in processDecodes() method which is invoked during apply request values phase.
Related
We do have a small page which is using the viewParam to convert a given Id to a concrete object. This converter is called on leaving (blur) of an inputText field, which is validated. Why? Could I rework this, so that the converter is not called every time?
This is annoying, because the converter calls the set-method for the corresponding object in the BackingBean and this bean is then null, if the page is called the first time for creating this object.
<f:metadata>
<f:viewParam name="id" value="#{bean.object}"
converter="#{objectConverter}"
converterMessage="#{msgs['converter.msg.object']}"/>
<f:viewAction action="#{bean.init}"/>
</f:metadata>
<p:inputText id="text" value="#{cc.attrs.value}"
styleClass="inputTextValidated"
required="#{cc.attrs.required}"
requiredMessage="#{cc.attrs.requiredmessage}"
label="text" validatorMessage="#{cc.attrs.msg}" title="#cc.attrs.title}"
readonly="#{cc.attrs.readOnly}">
<cc:insertChildren/>
<p:ajax update="msg_text" event="blur"/>
</p:inputText>
<p>
<p:message id="msg_text" for="text" display="msg"/>
</p>
If we do not use a converter but just the viewAction to convert the Id to the corresponding object (or create a new object if applicable), everything is fine. Is this the only/correct solution for this problem?
We do use primefaces 6.1 with CDI. The converter is a #Named and #ApplicationScoped bean implementing the Converter Interface.
Using p:fragment around the inputtext-field did not help either.
That is the nature of how JSF works. If you want to not have it do that I suggest you check out OminFaces ViewParam: http://showcase.omnifaces.org/components/viewParam
From their documentation:
Stateless mode to avoid unnecessary conversion, validation and model
updating on postbacks The standard UIViewParameter implementation
calls the model setter again after postback. This is not always
desired when being bound to a view scoped bean and can lead to
performance problems when combined with an expensive converter. To
solve this, this component by default stores the submitted value as a
component property instead of in the model (and thus in the view state
in case the binding is to a view scoped bean).
The standard UIViewParameter implementation calls the converter and
validators again on postbacks. This is not always desired when you
have e.g. a required="true", but the parameter is not retained on form
submit. You would need to retain it on every single command
link/button by . To solve this, this component doesn't call
the converter and validators again on postbacks.
I'm using an <f:viewParam> to pass a parameter as follows.
<ui:define name="metaData">
<f:metadata>
<f:viewParam name="id" value="#{bean.entity}" converter="#{converter}"/>
</f:metadata>
</ui:define>
Is it possible to process this <f:viewParam>, only when the page is loaded/refreshed?
It is just because the converter as specified with the <f:viewParam> is costly that converts the value passed through the query-string to a JPA entity. Hence, it involves an expensive database transaction, even when doing ajaxical postbacks using components like <p:commandButton>, <p:commandLink> which is unnecessary.
So, when for example, a <p:commandLink> (ajaxical) is clicked, the expensive business service (in the converter) should not be executed. Can this be done?
This somehow works (strange enough nevertheless), when the rendered attribute is evaluated against facesContext.postback like rendered="#{not facesContext.postback}" but the attribute rendered is not documented. Hence, it is unreliable.
You can achieve this by creating a custom tag extending <f:viewParam> wherein you store the submitted value as an instance variable which isn't stored in JSF view state instead of in the JSF view state as the <f:viewParam> by default does. By end of request, all UI component instances are destroyed. They are recreated in beginning of the request. When submitted value is null, then it won't call the converter nor the model setter. This all is elaborated in Arjan Tijms' blog.
OmniFaces offers already since version 1.0 a ready to use solution in flavor of <o:viewParam>, see also my own blog on that. Based on your question history, you're already using OmniFaces, so all you basically need to do is to replace f: by o:.
<ui:define name="metaData">
<f:metadata>
<o:viewParam name="id" value="#{bean.entity}" converter="#{converter}"/>
</f:metadata>
</ui:define>
This won't call the model setter (nor the converter) during postbacks on the same view.
This somehow works (strange enough nevertheless), when the rendered attribute is evaluated against facesContext.postback like rendered="#{not facesContext.postback}" but the attribute rendered is not documented. Hence, it is unreliable.
That's because the <f:viewParam> is in essence an UIInput component (else it wouldn't be able to perform conversion, validation, model-update and all that stuff like usual input components) which is thus just an UIComponent supporting a rendered attribute. This is however not explicitly documented as it actually doesn't render anything to the HTML output (that's also why it's a f:xxx, not a h:xxx). But with this attribute you can actually control the behavior during postback as this attribute is also evaluated in processDecodes() method which is invoked during apply request values phase.
What is the difference between <f:viewParam> and <f:param> in JSF 2.1?
Simply put:
<f:viewParam> is used inside <f:metadata> to attach an UIViewParameter as metadata for the current view. For example, if you access the page myapp/check.jsf?id=3 and your check.jsf page has this:
<f:metadata>
<f:viewParam name="id" value="#{mrBean.id}"/>
</f:metadata>
The value 3 will be set on mrBean's id property when the page is loaded.
On the other hand, <f:param> sets a parameter in the parent (enclosing) component of this tag, accessible later by obtaining the component's parameters themselves. This is in particular really powerful (yet, disastrous if used wrong) because through EL you can achieve some interesting results.
It can be used in different contexts. This link provides an interesting range of applications.
w.r.t. How to execute action on GET request with f:viewParam?
<f:metadata>
<f:viewParam name="id" value="#{tInputBean.id}" />
<f:event type="preRenderView" listener="#{tInputBean.init}" />
</f:metadata>
I'm interested to know whether it matters if a preRenderView f:event is placed inside the f:metadata or not. I've checked the Java EE6 tutorial, Java Server Faces 2.0 Complete Reference, and Core JSF2, and none of them have examples of f:event inside f:metadata, but I've seen lots of examples online like this.
JSF2 Compl.Ref says p.540
The f:metadata tag encapsulates the set of elements used to specify
the metadata for a Facelet view, and therefore must be a child of the
f:view tag and may not appear in a template. As of JSF2.0, the only
purpose of this tag is to encapsulate f:viewParam tags.
Does placing the f:event (often used to support an f:viewParam) inside the f:metadata have a special meaning, or is it just to help group it alongside the f:viewParam visually/logically ?
No, the <f:event> is not strictly required to be placed inside <f:metadata>. It can be attached to any component. It's indeed for pure self-documentary purposes placed inside the <f:metadata> whenever you have a bunch of <f:viewParam>s and would like to hook a <f:event> to invoke an action after all those view parameters have been set. It can even be placed outside/before those <f:viewParam>s, but it makes the code not more self-documenting.
Note that in the upcoming JSF 2.2, a new <f:viewAction> tag will be introduced which in turn is supposed to replace the <f:event type="preRenderView"> in the <f:metadata>.
I've got a page called trip.xhtml where I take parameters out of the URL using the following code:
<f:metadata>
<f:viewParam name="tripid" value="#{tripBean.tripId}" />
<f:viewParam name="seats" value="#{tripBean.seats}" />
<f:event type="preRenderView" listener="#{tripBean.processParams}" />
</f:metadata>
The TripBean looks like this (simplified):
#ManagedBean
#RequestScoped
public class TripBean implements Serializable {
private static final long serialVersionUID = -4885781058258859229L;
private Long tripId;
private int seats;
// Getters and setters for tripId and seats
On the bottom of the trip.xhtml page I have a h:link:
<h:link outcome="/customer/booking.xhtml" value="Book this trip"
includeViewParams="true" />
What I expect is that the URL I get when I click this link is something like "/customer/booking.jsf?tripid=2&seats=1". This is only the case when I put the following code on my booking.xhtml page:
<f:metadata>
<f:viewParam name="tripid" value="#{tripBean.tripId}" />
<f:viewParam name="seats" value="#{tripBean.seats}" />
</f:metadata>
Although what I actually want is to use another bean. Changing the code to:
<f:metadata>
<f:viewParam name="tripid" value="#{bookingBean.tripId}" />
<f:viewParam name="seats" value="#{bookingBean.seats}" />
</f:metadata>
The BookingBean also has 2 properties tripId and seats which are identical to the TripBean, but when I try to click the link now, I only see a seats-parameter which is set to 0. ("/customer/booking.jsf?seats=0")
Does anyone have any idea why I can't seem to pass the viewparams to the other page when I'm trying to use another bean to store them in? And IF it is impossible to store it in another bean, how can I put those values from TripBean in BookingBean?
Quick work-around I used:
Not using includeViewParams="true" , but adding parameters to the link manually (see below) "fixes" the problem. Although I'm still wondering why it won't work with includeViewParams!
<h:link outcome="/customer/booking.xhtml" value="#{msg['page.trip.booking']}">
<f:param name="tripid" value="#{tripBean.tripId}" />
<f:param name="seats" value="#{tripBean.seats}" />
</h:link>
f:viewParam works exactly like h:inputText. This means that it uses the same expression as a source (when rendering) and as a target (when updating the model). If you had:
<h:inputText value="#{a.test}" />
You would never ask "how to make the inputText read from b.foo and write to a.test", yet everyone seems to expect such behavior from f:viewParam.
Anyway, there is a simple answer. To append any values to link, you just need to use f:param:
<h:link outcome="/customer/booking.xhtml" value="Book this trip" >
<f:param name="tripid" value="#{bookingBean.tripId}" />
<f:param name="seats" value="#{bookingBean.seats}" />
</h:link>
The link content corresponding to the following tag:
<h:link outcome="/customer/booking.xhtml" value="Book this trip"
includeViewParams="true" />
is generated during the render-response phase of the request for the trip.xhtml view. If you need the URL to contain the view parameter values, then you must provide these values in the URL used to access the view, or you must set these values in the model, before the render-response phase is complete. If you do not perform either of these, the generated hyperlink will contain the default values for the view parameters.
In simpler words, you must:
either ensure that the trip.xhtml view is accessed with the necessary parameters: trip.xhtml?tripid=x&seats=y, especially if the view is to be accessed with parameters at all times.
or you must set the values in a method that gets executed before the link is rendered by the JSF runtime. The constructor of the BookingBean class or a #PostConstruct annotated method in the class would be ideal places to set the values. You could also reset/update the values of the bean in other methods of your managed bean, in the event of actions being performed in the view. Note, that JSF runtime will invoke getTripId and getSeats to include the values of the view parameters tripId and seats in the resulting URL, so you ought to verify the behavior of these methods as well.
Your question on why you are unable to specify bookingBean in the EL expression for booking.xhtml, instead requiring you to specify the supposedly unexpected value of tripBean is due to the fact that the includeViewParams attribute of the link tag, will include the parameters of the to-view and not the from-view. Simply put, the JSF runtime will invoke bookingBean.getTripId() and bookingBean.getSeats() and not tripBean.getTripId() and tripBean.getSeats().
While this might seem counter-intuitive, you ought to understand that the JSF specification treats this scenario quite differently. In most interactions performed by a user, the action URL of a component is generated when the user performs the action and not until then. The link tag on the other hand, requires preemptive computation of the URL, and hence the JSF runtime treats this quite differently as "pre-emptive navigation". When the URL is being constructed, the objects pertaining to the view parameters of the target view must be accessible, in order for the URL to be meaningful. The reason for the values being 0 in the URL, is that a new BookingBean instance is created during this evaluation and the default values are being used instead. You can quite obviously avoid this by using the TripBean instead (and most examples of includeViewParams demonstrate this), or you can set values during the construction of the BookingBean object.