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>.
Related
As I know <f:viewParam> we use for GET parameter.
Also I know <f:viewAction ...> we can use for acess check usually for each specific situation (for specific view/bean). As well as calls at the beginning. So I’ve done. Specifically I have a bean - ViewScopedBean myBean. And a view (.xhtml) which includes
<f:metadata>
<f:viewParam name="param" value="#{viewScopedBean.param}" />
<f:viewAction action="#{viewScopedBean.doCheck()}" />
</f:metadata>
But Setter and method are not call.
I use JSF 2.2.9.
And I try change namespaces xmlns.jcp.org and java.sun.com. But i’ve not received results.
Could you help me with this question? What should I check? What should I do for correct result?
Thanks a lot for you attention and help.
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.
I have a question about the idea behind the fact, that only UIForm got the attribute prependId. Why is the attribute not specified in the NamingContainer interface? You will now probably say that's because of backward compability but I would preferre breaking the compability and let users which implement that interface, also implement methods for the prependId thing.
The main problem from my perspective about the prependId in the UIForm component is, that it will break findComponent()
I would expect that if I use prependId, then the NamingContainer behaviour would change, not only related to rendering but also when wanting to search for components in the component tree.
Here a simple example:
<h:form id="test" prependId="false">
<h:panelGroup id="group"/>
</h:form>
Now when i want to get the panelGroup component I would expect to pass the string "group" to the method findComponent(), but it won't find anything, I have to use "test:group" instead.
The concrete problem with that is, when using ajax with prependId="false". The ajax tag expects in the attributes update and process, that the values care of naming containers. It's a bit strange that when I use prependId="false" that I have to specify the full id or path, but okay.
<h:form id="test" prependId="false">
<h:panelGroup id="group"/>
</h:form>
<h:form id="test1" prependId="false">
<h:commandButton value="go">
<f:ajax render="test:group"/>
</h:commandButton>
</h:form>
Well this code will render without problems but it won't update the panelGroup because it cannot find it. The PartialViewContext will contain only the id "group" as element of the renderIds. I don't know if this is expected, probably it is but I don't know the code. Now we come to the point where the method findComponent() can not find the component because the expression passed as parameter is "group" where the method would expect "test:group" to find the component.
One solution is to write your own findComponent() which is the way I chose to deal with this problem. In this method i handle a component which is a NamingContainer and has the property prependId set to false like a normal UIComponent. I will have to do that for every UIComponent which offers a prependId attribute and that is bad. Reflection will help to get around the static definition of types but it's still not a really clean solution.
The other way would be introducing the prependId attribute in the NamingContainer interface and change the behaviour of findComponent() to work like described above.
The last proposed solution would be changing the behaviour of the ajax tag to pass the whole id, but this would only solve the ajax issue and not the programmatic issues behind the findComponent() implementation.
What do you think about that and why the hell is it implemented like that? I can't be the first having this problem, but I wasn't able to find related topics?!
Indeed, UIComponent#findComponent() as done by <f:ajax render> fails when using <h:form prependId="false">. This problem is known and is a "Won't fix": JSF spec issue 573.
In my humble opinion, they should never have added the prependId attribute to the UIForm during the JSF 1.2 ages. It was merely done to keep j_security_check users happy who would like to use a JSF form with JSF input components for that (j_security_check requires exact input field names j_username and j_password which couldn't be modified by configuration). But they didn't exactly realize that during JSF 1.2 another improvement was introduced which enables you to just keep using <form> for that instead of sticking to <h:form>. And then CSS/jQuery purists start abusing prependId="false" to avoid escaping the separator character : in their poorly chosen CSS selectors.
Just don't use prependId="false", ever.
For j_security_check, just use <form> or the new Servlet 3.0 HttpServletRequest#login(). See also Performing user authentication in Java EE / JSF using j_security_check.
For CSS selectors, in case you absolutely need an ID selector (and thus not a more reusable class selector), simply wrap the component of interest in a plain HTML <div> or <span>.
See also:
How to select JSF components using jQuery?
How to use JSF generated HTML element ID with colon ":" in CSS selectors?
By default, JSF generates unusable ids, which are incompatible with css part of web standards
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.