The <meta http-equiv> tags are only used when the HTML file in question is been opened from a non-HTTP resource such as local disk file system (via file:// URI) and not when the HTML file in question is been opened from a real HTTP resource (via http:// URI). Instead, the real HTTP response headers as … Read more
JSF’s built-in declarative tags are ill-suited for handling this sort of recursion. JSF builds a stateful component tree that is persisted between requests. If the view is restored in a subsequent request, the view state may not reflect changes in the model. I would favour an imperative approach. You have two options as I see … Read more
found out that the lazy datamodel must be the same instance on postback request, even a new instance with the very same values will not work. so it must be provided from at least a @ViewScoped bean.
You can try either of the following , I vote number one, it’s a cleaner design IMO Bring the <p:dialog/> outside of the general <h:form/> and put an <h:form/> inside it instead <p:dialog id=”dlg” header=”#{messages.chooseSkillLevel}” widgetVar=”dlg” modal=”true” dynamic=”true”> <h:form> <h:dataTable value=”#{editSkills.skillsAndLevels}” var=”skillslevel”> <h:column> #{skillslevel.skill.umiejetnosc} </h:column> <h:column> <p:selectOneMenu value=”#{skillslevel.level}” > <f:selectItems value=”#{editSkills.levels}” var=”level” itemLabel=”#{level.stopien}” itemValue=”#{level.id}” /> … Read more
@ViewScoped beans are stored in HTTP session. Any objects which are stored in the HTTP session needs to implement Serializable. See also JSF managed bean causing java.io.NotSerializableException during Tomcat deployment and java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException. The NotSerializableException is usually self-explaining since it mentions the full qualified name of the class which needs to be serialized … Read more
I just did some tests in my playground project and realized it’s actually possible to keep the state of the flash parameters even if you GET the page again, using {flash.keep}. That’s how the JSF docs explain it: The implementation must ensure the proper behaviour of the flash is preserved even in the case of … Read more
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. … Read more
You could create a custom EL function for this with which you can ultimately end up like: <h:commandLink … title=”#{my:format(msg[‘someMessage’], someBean.value)}” /> You can use the MessageFormat API to perform the job, exactly as <h:outputFormat> is doing under the covers. An alternative is to create a custom component which does the same as JSTL’s good … Read more
The Mojarra’s implementation of the JSF2 Flash scope had a lot of problems. Most of them were resolved with every new Mojarra release. Currently, with the latest Mojarra version, the 2.1.6, there’s as far as I know still only one major open problem: it won’t work if you redirect to a different base path. See … Read more
Redirecting in a @PostConstruct might be too late if the response is already committed. I.e. when the first few bytes of the response are already been sent to the client. This is a point of no return. That can in your case happen when the backing bean is referenced (and thus constructed) for the first … Read more