General | Licensing | Support Policy | Project Infrastructure | Compatibility | Ajax | DataTable and TreeTable | TabbedPane and TabSet | Miscellaneous
OpenFaces is a JSF library that provides an extended set of advanced highly customizable JSF components, an Ajax framework and a validation framework. It extends the standard set of UI components with such sophisticated widgets as TreeTable, DataTable, DayTable, SuggestionField, DateChooser, Chart, and many others. Besides the components, OpenFaces has an Ajax framework and a validation framework. Ajax framework allows adding Ajax-based interaction to the pages where Ajax capabilities built into components are not enough, and Validation framework shifts the traditional JSF validation to the client side, provides new validators and a new kind of error presentation.
To learn when the next version of OpenFaces will come out and what new features or components will it have, see the OpenFaces Roadmap.
The OpenFaces components were tested to work in both Quirks and Standards Compliance modes.
I see that OpenFaces is dual licensed, can I use OpenFaces in a commercial project for free?
Yes you are welcome to use OpenFaces in commercial projects for free, like any other LGPL licensed libraries. The additional commercial license doesn't narrow the volume of OpenFaces users, but actually increases it, since it provides an additional way to use OpenFaces for companies that have a policy of not using open-source licensed software.
OpenFaces Licensing Models
OpenFaces is licensed under a dual license model. The functionality of the product is the same for both licensing options.
You can license OpenFaces binaries along with source code packages under the terms and conditions of a GNU LESSER GENERAL PUBLIC LICENSE (Version 2.1, February 1999).
Alternatively you can opt for a commercial license for OpenFaces under the terms and conditions of the Product License Agreement.
It is free of charge.
This license does not restrict using OpenFaces in your proprietary software, though it has some peculiarities. As it follows from LGPL conditions, you may freely copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.
We do administer OpenFaces support community, but we cannot guarantee our feedback to all your posts.
The Commercial License exempts you from all the restrictions of the open-source license. This license is issued to a person or company and the license contains your name or the name of your company. Having once purchased the Commercial License you can perpetually use OpenFaces binaries in all your projects without any annual renewals, subscriptions or additional fees to us.
In addition to the license you'll receive a personal yearlong support via direct email with our Software Engineers and access to JIRA to track progress for your issues.
We guarantee our feedback to your support requests within 1 business day.
Commercial License doesn't govern source code issues.
Free support is provided via our support forum. It is constantly watched and administered by our support engineers, so we guarantee that none of your messages remains unnoticed. Though we do not guarantee that we will answer all the posts.
If you need to secure our feedback, you can consider our paid support. This will ensure our feedback to your request within one business day. It covers bugfixes and some assistance with the use of OpenFaces.
All holders of commercial licenses get one year of this support automatically. If you use Openfaces under LGPL, but you are interested in getting our paid support, please send your request to licensing@teamdev.com.
At OpenFaces web site you can find the detailed info about the project including demos, source codes, binaries and documentation, download the latest stable, nightly build or get the builds history. Refer to the readme.txt files in the respective packages for building instructions.
OpenFaces Community forum is mainly designed for sharing experiences, ideas, thoughts and similar OpenFaces-related discussions.
If you want to submit a bug or request a feature, please use JIRA Issue Tracking System.
You can check out the entire OpenFaces project including the library itself, the tests and the demos from our SVN. The current development version of the project is available at the following URL: http://svn.openfaces.org/trunk. This project can be built in three ways: using IntelliJ Idea IDE, Eclipse IDE, or Ant build tool. See the Building OpenFaces.html document in project's root directory for instructions.
The OpenFaces developer's guide, the tag library documentation and the API reference are available online and are included in the OpenFaces binary distribution packages that can be found at the OpenFaces downloads page.
OpenFaces forum is available at the following address: http://support.teamdev.com/community/openfaces
OpenFaces was tested to work with the following JSF implementations:
Sun Reference Implementation (Mojarra) 1.2
Apache MyFaces Implementation 1.2
OpenFaces was tested to work with the following application servers:
Apache Tomcat 6.0
IBM WebSphere 6.0 -6.1
Bea WebLogic 9.2
JBoss 4.0 - 4.2
Glassfish
Jetty 6.1.x
OpenFaces can be used to develop JSR-168 Portlets. The current version of OpenFaces has been tested to work with the following portal servers:
JBoss Portal 2.4.x and 2.6.x
Liferay Portal 4.2.1
JetSpeed 2.0 Portal
There is no IDE support in the current version of OpenFaces. We are planning to add support for the popular IDEs in one of the future releases of OpenFaces. To know about our nearest plans, please see the Roadmap.
OpenFaces components are fully compatible with the JBoss Seam framework. The OpenFaces components have been tested to work with JBoss Seam version 2.0 and 2.1.
OpenFaces library is fully compatible with JBoss RichFaces library version 3.3.1 including its components and Ajax framework.
OpenFaces and Tomahawk components can be used in the same application. However, there are some issues with some of the Tomahawk components. Most of the compatibility problems take place in cases when embedding Tomahawk components inside of OpenFaces components.
OpenFaces and Trinidad are not fully compatible yet. There are some issues when the OpenFaces and Trinidad components are used within one page.
OpenFaces and ICEfaces components are not compatible currently.
If some of the content of ajaxable OpenFaces components disappears after performing Ajax request, the reason might be that you use the <f:loadBundle> component within the OpenFaces Ajax-enabled components. The solution is to use the <o:loadBundle> component instead.
When any OpenFaces Ajax request is in progress, the "Loading..." message appears in the upper-right corner of the screen. There is no possibility to display this message while Ajax4jsf's Ajax request is in progress. And there is no possibility to display the a4j:status component while an Ajax request in OpenFaces components is being executed. However, you can customize the Ajax progress message for the whole application by using the org.openfaces.ajaxMessageHTML application scope parameter in web.xml or for the particular page by using the <o:defaultProgressMessage> tag. For more details, please see the documentation.
There is no dedicated feature not to show OpenFaces Ajax progress message, however it is possible to utilize features of customizing its appearance for achieving this effect. The idea is to customize the progress message to be invisible using the "display: none" CSS declaration. You can either customize the Ajax progress message for the whole application by using the org.openfaces.ajaxMessageHTML application scope parameter in web.xml or for the particular page by using the <o:defaultProgressMessage> tag. For more details, please see the documentation.
Here's an example of disabling Ajax progress message using the <o:ajaxSettings> tag:
<o:ajaxSettings>
<f:facet name="progressMessage">
<o:defaultProgressMessage style="display: none;"/>
</f:facet>
</o:ajaxSettings>You can get the total number of filtered rows using the getTotalRowCount() method of the DataTable component. You should use the component binding to be able to use this method from your backing bean.
At the present, there is no public API to get the total number of filtered rows for the TreeTable component. However, you can use the getRowCount() method. This method returns the number of rows that are actually loaded to the client. If you have the preloadedNodes attribute set to "all", the getRowCount() method will return the number of filtered rows.
There is a known issue that the DataTable and TreeTable components cannot be used inside DataTable, TreeTable or any other JSF components that replicate their child components during rendering. We are going to add support for such configurations in one of the future releases.
Server-side event handlers can be aware of the row where an event occurs by checking the request-scope variables that refer to the current row data object and current row index. See the appropriate documentation section. You can use the org.openfaces.util.Faces.var utility method if you need to retrieve a request-scope variable from a backing bean.
In some situations in Facelets application with Sun reference implementation 1.2, you can get the "duplicate component IDs" exception in the pages with the DataTable or TreeTable. This is actually not OpenFaces related problem and it can be reproduced in the application without OpenFaces at all. You can work around this problem by setting the id attributes for the all child components of the DataTable or TreeTable.
This problem can only be seen for filters with the "searchField" filter type. The problem appears on the pages having the "standards" rendering mode, which is triggered by DOCTYPE specified on the first line of your page. The filter's text field in this case is slightly wider than it should be, which results in its right edge intersect its cell's boundaries. You can use on of the following workarounds:
Switch your page to use the "quirks" rendering mode. You can do this either by removing the DOCTYPE declaration from your page, or changing it appropriately, for example as follows:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">Remain in the "standards" mode but specify the filterRowStyle="padding-right: 20px" for your table. Note that the actual amount of padding required to fix this might depend on the actual configuration of your table.
You can specify the objects of different types for different TreeTable levels. First you should define a dynamic tree structure by specifying the <o:dynamicTreeStructure> tag and the nodeChildren attribute. The attribute should be specified as a value-binding expression, which is calculated for each node to retrieve the node's children. You can use the org.openfaces.util.Faces.var method to get the current node. Then you should return the node children depending on the current node type.
You can programmatically specify whether a particular node is collapsed or expanded with its nodeKey. To do so, you should do the following:
1. Bind the expansionState attribute of the TreeTable tag to the variable of org.openfaces.component.table.ExpansionState type in the backing bean.
2. Initialize this variable as follows:
private ExpansionState myTreeTableExpansionState = new DynamicNodeExpansionState(new AllNodesCollapsed());3. Use the setNodeExpanded(TreePath keyPath, boolean expanded) method to specify whether the node is expanded or collapced. As the first parameter of the TreePath class, you should use nodeKey of the required node. The second parameter is the TreePath of its parent. For example:
myTreeTableExpansionState.setNodeExpanded(new TreePath("message10",null),true);Here, "message10" is a nodeKey of the node that should be expanded and null means that it is a root node. Please also see the corresponding documentation section.
Note that if you want to expand the node, for example from the third level, you should expand all its parent nodes first. So you will need to make several setNodeExpanded method calls to expand nodes deep in a hierarchy of nodes.
There is no built-in feature to add pagination to the TreeTable component. However, you can still implement similar behavior by implementing your backing bean to provide only the partial tree structure, and changing the provided data set when pressing "next" and "previous" buttons. To do so, you should display the "next" and "previous" buttons in one of the child nodes on the tree branch that you need to have the pagination functionality, for example in the last node of each tree branch. You can use the <o:row> and <o:cell> tags to do so (see the documentation). In the nodeChildren attribute you should provide only the required number of items for the current "page". When the user clicks the "next" or "previous" button, you should reload the TreeTable component by using O$.ajax.request JavaScript function (or the <o:ajax> component) and change the currently displayed page number so that your backing bean provide the new set of child nodes. See also the documentation for the O$.ajax.request function.
We are planning to implement a built-in TreeTable pagination feature in one of the future releases of OpenFaces.
To change the +/- sign of the TreeTable component, use the expandedToggleImageUrl and collapsedToggleImageUrl attributes of the <o:treeTable> tag. You can see the example in the "Preloading Nodes" TreeTable demo. The source code of the OpenFaces demo is available at the Download page.
The TabbedPane component represents a set of pages for containing other components and a set of tabs for switching between these pages. Given the fact that the TabbedPane is a container, a developer can use different loading modes for loading the pages' content. For example, you can use Ajax to load the content of a TabbedPane page when it is selected for the first time.
The TabSet component is just a set of tabs that look like the ones located inside of the TabbedPane, but without any containers. So the TabSet can be used like a switch enabling a developer to manually adjust the page contents depending on a selected tab.
The TabbedPane component should be included in the <h:form> component to save its state between page submissions. And it's incorrect to create nested <h:form> components. Therefore it's not possible to include <h:form> component as a child tag for every TabbedPane's tab in the current version of OpenFaces.
In order for OpenFaces components to work properly, they should be placed in the <h:form> or an analogous tag.
The dynamic creation of the OpenFaces components from the Java code is the same as for the standard JSF components. However, there is the createSubComponents() method that should be called for the following components after the component is created and its properties are configured: FoldingPanel, TabbedPane, DropDownField, SuggestionField, TableColumn, TreeColumn. The typical creation of the OpenFaces components is shown in the following example:
FacesContext facesContext = FacesContext.getCurrentInstance();
Application application = facesContext.getApplication();
TabbedPane tabbedPane = (TabbedPane) application.createComponent(TabbedPane.COMPONENT_TYPE);
tabbedPane.setId("myTabbedPane");
tabbedPane.setStyleClass("tabbedPane");
...
tabbedPane.createSubComponents(facesContext);Currently, CSS width does not indeed affect the width of the DateChooser. The DateChooser was specifically designed to have the width equal to the pop-up Calendar's width.
However, you can declare the width for a DateChooser with the 'important' CSS modifier. For example:
<o:dateChooser style="width:70px!important;"></o:dateChooser>There are no comments on this document