This is what I have in the output HTML document (produced by JSF 2.0/Mojarra 2.0.3):
<input type="hidden" name="javax.faces.ViewState"
id="javax.faces.ViewState" value="4267906931114993858:-6309146738430577631"
autocomplete="off" />
My document should be XHTML 1.1 compliant, where attribute autocomplete is not valid and id attribute is duplicated over all forms. How to instruct JSF to produce everything strictly compliant to XHTML?
See.
<context-param>
<param-name>com.sun.faces.autoCompleteOffOnViewState</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.enableViewStateIdRendering</param-name>
<param-value>false</param-value>
</context-param>
The non unique use if the ID javax.faces.ViewState is a bug that appears Oracle will not fix. They have closed these tickets. No workaround.
How to instruct JSF to produce
everything strictly compliant to
XHTML?
That's not a matter of "instructing" the JSF implementation with a simple flag. It's something that has to be continuously checked and thus only possible when it's considered important by the project. XHTML strict imposes a lot of restrictions and is probably therefore generally not considered worth supporting - see this bug. Note also that any component library you use also has to support it.
You'll have a lot more luck with XHTML 1.0 Transitional - I can confirm that MyFaces does produce valid XHTML 1.0 Transitional (once you set the context param org.apache.myfaces.RENDER_VIEWSTATE_ID to false).
There is a solution to this problem, it was created in version 1.2_14 of JSF. I think the problem is related to the way that Firefox operates during the reset event (input type=reset) on hidden fields. There is a problem where the client viewState that is on a hidden field gets an inconsistent state. The solution for this problem was disabled the auto-complete in a strict way (and this is not XHTML compliant). The most interesting thing is that until 1.2_14 almost everybody lived with this potential error. So the JSF-RI implementation (Mojarra project) allowed a developer to disable this option using a parameter that you can edit in your web.xml, and this auto complete won't print anymore.
<context-param>
<description>Put your description here :)</description>
<param-name>com.sun.faces.autoCompleteOffOnViewState</param-name>
<param-value>false</param-value>
</context-param>
It is really difficult to produce valid XHTML pages with component based frameworks like JSF, but at least a solution exists for this problem.
It's not a good idea to disable autocomplete="off" for ViewState hidden input fields, because then Firefox doesn't refresh the ViewState-Id on page refresh. This causes unusable JSF forms and functionalities.
See this post for details.
Related
I started using JSF 2.0 with Facelets recently and got puzzled by new composite components knowing existing <ui:include> and other templating techniques offered by Facelets 1.x.
What is the difference between those approaches? Functionally they seem to offer about the same: <ui:param> vs <cc:attribute>, <ui:insert>+<ui:define> vs tag files, reuse of the existing templates. Is there anything besides syntax and clear interface specification in case of composite components? Could performance differ?
What is the difference between those approaches?
Facelet templates
Use Facelet templates (as in <ui:composition>, <ui:include> and <ui:decorate>) if you want to split main page layout fragments into reuseable templates. E.g. header, menu, content, footer, etc.
Examples:
How to include another XHTML in XHTML using JSF 2.0 Facelets?
What is the real conceptual difference between ui:decorate and ui:include?
How to customize h:head when using ui:composition template?
How to change head elements of a page when using ui:composition
How to ajax-refresh dynamic include content by navigation menu? (JSF SPA)
Facelet tag files
Use Facelet tag files if you want to have a reuseable group of components in order to prevent/minimize code duplication. E.g. a group of label+input+message components. The major difference with composite components is that the output of a Facelet tag file does not represent a single UIComponent and may in some circumstances be the only solution when a composite component doesn't suffice. Generally, having an <ui:include> with one or more <ui:param> which passes a managed bean property (and thus not a hardcoded value) is a signal that the include file can better be a tag file.
Examples:
How to create a custom Facelets tag?
How to make a grid of JSF composite component?
How to create a composite component for a datatable column?
Primefaces outputLabel for composite component
Composite components
Use composite components if you want to create a single and reuseable custom UIComponent with a single responsibility using pure XML. Such a composite component usually consists of a bunch of existing components and/or HTML and get physically rendered as single component and is supposed to be bound to a single bean property. E.g. a component which represents a single java.time.LocalDate property by 3 dependent <h:selectOneMenu> components representing day, month and year, or a component which combines <p:fileUpload> and <p:imageCropper> into a single <my:uploadAndCropImage> referring a single custom com.example.Image entity as property.
Examples:
Our Composite Component wiki page
The BalusC Code: Composite Component with multiple input fields
Split java.util.Date over two h:inputText fields representing hour and minute with f:convertDateTime
Select all items in Multiple SelectManyCheckBox with dynamic ids
Extending JSF commandLink component
Avoiding duplicate ids when reusing facelets compositions in the same naming container
Custom components
Use a custom component whenever the functionality cannot be achieved with Facelet tag files or composite components, because of the lack of support in the standard/available set of components. Generally when you want a high degree of control and/or customization of the decoding and/or encoding, and also to offer the endusers the possibility to relatively easily extend/override the decoding and/or encoding. Examples can be found over all place in source code of open source component libraries such as PrimeFaces and OmniFaces.
Tag handlers
When you want to control the building of the JSF component tree instead of rendering of the HTML output, then you should use a tag handler instead of a component.
Examples:
Custom Facelet component in JSF
How can I access the content of something created with <ui:define> programmatically?
Conditional render in tagfile depending on whether the attribute is specified or not
Performing a redirect, when conversion / validation associated with query parameters fails
Example projects
Here are some example projects which utilize all of above mentioned techniques.
Java EE Kickoff App (templates - includes - tagfiles - composite)
OmniFaces Showcase (templates - includes - tagfiles - composite)
Could performance differ?
Technically, the performance concern is negligible. The choice should be made based on the concrete functional requirements and the final degree of abstraction, reusability and maintainability of the implementation. Each approach has its own well definied purpose and limitations.
Composite components do however have a significant overhead during building/restoring of the view (specifically: during saving/restoring the view state). And, in older versions of Mojarra, composite components had performance issues with assigning default values, this is already fixed since 2.1.13. Also, Mojarra had a memory leak when a <cc:attribute method-signature> is used for method expressions, basically the entire component tree is re-referenced in HTTP session, this is fixed since 2.1.29 / 2.2.8. The memory leak can be bypassed in older 2.1 versions as below:
<context-param>
<param-name>com.sun.faces.serializeServerState</param-name>
<param-value>true</param-value>
</context-param>
Or in older 2.2 versions as below:
<context-param>
<param-name>javax.faces.SERIALIZE_SERVER_STATE</param-name>
<param-value>true</param-value>
</context-param>
Still, when you have relatively "a lot of" composite components, and you have javax.faces.STATE_SAVING_METHOD set to client, then the performance will be a pain. Do not abuse composite components if you merely want the basic functionality which is already possible with a simple include file or tag file. Do not use the ease of configuration (read: no *.taglib.xml file needed) as an excuse to prefer composite components over tag files.
When using Mojarra 2.2.10 or older, do not forget to disable the relatively short Facelets refresh period for production mode:
<context-param>
<param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>
<param-value>-1</param-value>
</context-param>
Do not use this setting for development, otherwise you've to restart the whole server to get changes in Facelets files to be reflected! Mojarra 2.2.11 and newer, and MyFaces already defaults to -1 when javax.faces.PROJECT_STAGE is not set to Development.
we're delevoping a JSF application with MyFaces 2.1.
For reloading xhtml on-the-fly, we set
<context-param>
<param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>
<param-value>0</param-value>
</context-param>
This works fine, but slows down the application (about times 5 compared to value -1. For production it's set to -1 of course).
This makes me wondering if there's any way to change this parameter on demand. Thus I could set it to -1 and create something like a servlet in order to trigger the xhtml reload.
Is something like this possible or has anyone an idea for refreshing xhtml on demand?
Thanks a lot!
Problem
I'm trying to validate a mandatory GET request parameter.
In the view I've added a corresponding viewParam tag.
<f:metadata>
<f:viewParam name="customerId" value="#{customerDetailBean.customerId}"/>
</f:metadata>
And my CDI bean looks like this
#Model
public class CustomerDetailBean {
#NotNull
private Integer customerId;
public Integer getCustomerId() {
return customerId;
}
public void setCustomerId(Integer customerId) {
this.customerId = customerId;
}
}
When I use the following request, validation works fine and the expected validation message is displayed.
http://localhost:8080/getsupport/customerdetail.jsf?customerId=
However, when I change the request by removing the parameter customerId, validation is skipped and no message is shown.
http://localhost:8080/getsupport/customerdetail.jsf
Is there a way to make it work as expected?
Workaround
I've changed my viewParam declaration to
<f:metadata>
<f:viewParam name="customerId" value="#{customerDetailBean.customerId}" required="true" />
</f:metadata>
That updated version works fine with the second request. Anyway I would prefer to use bean validation.
My setup
Mojarra JSF 2.2.7
Weld 2.2.1.Final
Hibernate Validator 5.1.1.Final
Tomcat 7.0.54
web.xml
<context-param>
<param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name>
<param-value>true</param-value>
</context-param>
This is, unfortunately, "working as designed". All validation is skipped when nothing's been submitted. Only the <f:viewParam required> has special treatment. It's also considered when nothing's been submitted. See also UIViewParameter#processValidators() javadoc and source code.
In the Mojarra issue tracker I can only find issue 3058 as a related issue, whereby the <f:validateRequired> isn't being considered. This is technically actually exactly the same problem as you're facing with #NotNull. I've created issue 3339 on this.
In the meanwhile, your best bet is falling back to required="true". A custom component can also, but as far as I see this isn't going to be trivial.
Update: after all, the fix is relatively easy and has been implemented in OmniFaces <o:viewParam> in the current 2.0 snapshot release.
Prior to JSF 2.0, validation was simply not run at all on fields whose values were
empty or null. JSF 2.0 changes this default behavior slightly. If the JSF runtime is executing in
an environment that supports bean validation, empty fields are validated by default. Otherwise,
the behavior is the same as it was prior to JSF 2.0: empty fields are not validated.
Since Tomcat(& Jetty) is not a J2EE compliant server bean validation is not enabled by default. That is the reason why your validation is skipped.
To force JSF to validate empty fields, add this to your web.xml file:
<context-param>
<param-name>javax.faces.VALIDATE_EMPTY_FIELDS</param-name>
<param-value>true</param-value>
</context-param>
The Bean validation(JSR 303) can be configured on non j2ee compliant server with minimal configuartion(I have never configured this :)). In some way you have enabled bean validation and you have not above context param then jsf runtime would consider it as true and validate empty and null fields for validation.
But I suggest to use required attribute which is suggested experts for performance because using annotations invove reflections. So we could avoid for atleast in one case.
And ensure context param javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR is not set to true in web.xml.
To have a look at list of these parameters see
Overview of all JSF-related web.xml context parameter names and values
Hope this helps.
Can we change the name of faces-config.xml file or it should be the same name ?
In jsf 1.2 , default suffix is .jsp and jsf 2.0 default suffix is .xhtml? Can we have a default suffix as .jsf
What is the use of the below line?
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener> here
How to get a managed bean name, scope and request url programatically?
I have 1000 records in my database but i just want to show the records from 100 to 200 (in a jsf datatable? How can i do that?
How a request works in jsf?
What is re-render and rendered attributes? what is the use of those?
difference between f:param and f:attribute? where and when we use those?
Do we use none scope? in what scenario it will be used?
Can we change the name of faces-config.xml file
Yes, but then it ceases to be a faces-config.xml file. It's hard to see why you're even asking.
or it should be the same name?
If you want it to work, yes.
In jsf 1.2 , default suffix is .jsp and jsf 2.0 default suffix is .xhtml? Can we have a default suffix as .jsf
Yes.
What is the use of the below line?
<listener> <listener-class>com.sun.faces.config.ConfigureListener</listener-class> </listener> here
See this answer, which you could have found for yourself.
How to get a managed bean name, scope and request url programatically?
The name of a managed bean is fixed when you compile it, so I don't know why you're even asking. I don't know what 'get a scope' means. You can get the request URL from the ExternalContext.
I have 1000 records in my database but i just want to show the records from 100 to 200 (in a jsf datatable? How can i do that?
With a LIMIT clause in your SQL.
How a request works in jsf?
Far too broad to answer here.
What is re-render and rendered attributes?
reRender is part of RichFaces. rendered is part of JSF.
what is the use of those?
These things are documented. There's no need to ask about things like that here.
difference between f:param and f:attribute?
Ditto.
where and when we use those?
Ditto.
Do we use none scope?
If you need it.
in what scenario it will be used?
When you don't need any other scope.
This questions are pretty frivolous. You could have more usefully spent the time doing some research of your own. Don't let me stop you.
I have an h:selectOneMenu and an a4j:commandButton, the latter of which reRenders a component called content which looks like this:
<rich:panel id="content">
<a4j:include viewId="#{MyBacking.viewId}" />
</rich:panel>
When the response is rendered and the component loads the content of the new JSP page, the tabs contained in that page use a skin that is different from the rest of the app (I think default blue).
I've noticed that after the included code is loaded, if I hit refresh, although this causes the bean to reissue the page contents, the skin is properly assigned.
My web xml says:
<context-param>
<param-name>org.richfaces.SKIN</param-name>
<param-value>glassX</param-value>
</context-param>
<context-param>
<param-name>org.richfaces.CONTROL_SKINNING</param-name>
<param-value>enable</param-value>
</context-param>
<context-param>
<param-name>org.richfaces.CONTROL_SKINNING_CLASSES</param-name>
<param-value>enable</param-value>
</context-param>
Is this effect because RichFaces is in some way not in control of the rendering of the tabs at this point?
How can I ensure the tabs conform to the skin? All the documentation is relating to overriding a skin, and I'd rather not have to override and skin with the skin that it should already have.
Thanks
I am not sure if it will solve your problem, however you can try to force Richfaces to avoid using the default skin by setting a specific web.xml parameter:
<context-param>
<param-name>org.richfaces.LoadStyleStrategy</param-name>
<param-value>ALL</param-value>
</context-param>
You can find more details about this property here.
edited, to set the correct param-value, as stated in the comments.
I've just noticed I'd included a styleClass parameter - and because the jsp is now included didn't have access to the css facet reference.