The sample portlets require the following services:
They also require one of the following portlet containers:
They are able to be consumed by the following portals:
If you do not have the above software available, please visit the Oracle WebCenter Suite Home Page to obtain it.
The sample portlets will be deployed and configured on the selected portlet container. It is assumed that the reader is familiar with these processes on the selected container; if not please consult the product-specific documentation.
Technologies used by these samples include Java Portlets (JSR 168), JSP 2.0, JSTL, Web services, CSS, and JavaScript. For more information on these technologies, please refer to the Additional References.
Installation of the sample portlets will vary somewhat depending on the portlet container being used. Please consult the relevant documentation for the portlet container for more specific instructions, some of which may be found in the Additional References.
For many portlet containers the Java Web Archive (WAR) file may be deployed directly using various development and administration tools and utilities. If you are planning on exploring and modifying the sample code you should deploy this as an "exploded" archive on the file system. This may be done via an import utility, as in an IDE, or via a standard JAR or Zip utility.When using the portlets via Web Services for Remote Portlets (WSRP), please consult the product-specific instructions for creating the consumer and/or producers for the portlets. The portlets have been designed and tested with WSRP in mind, but there may be additional configuration and/or modifications to the code necessary depending on the way the server is configured.
The sample portlet does not provide container-specific security hooks and uses a simple user name based system for accessing the remote services. It assumes that the user exists on both the local and remote systems, and that the authentication is handled by the portal container. Additional security via common security realms, SSO, credential vaults, and the like will require configuration and possible code modifications.
The portlets work best when a rich text editor (RTE) is available. They were designed to use the FCKeditor, if it is present. If not a simple text area is provided , although with a diminished user experience. This editor may be obtained from the FCKeditor - Download page.
The archives contain a top level fckeditor directory which should be placed in the root of the web application. In Oracle Portal, the default installation location for the fckeditor directory is [ORACLE_Mid-Tier_HOME]/portal/images. For WebCenter (custom)applications, this directory would be under the HTML root directory (e.g. public_html). The portlet samples assume this editor and location by default. If this location is not used, or if a different RTE is to be used, (javascript) code for each portlet (blog.js, discussions.js, wiki.js located in the samples\webcenter\portlets\[wiki,blog,discussion]\js directory) must be modified to reflect the correct oFCKeditor.BasePath . To modify this location, open up the javascript file (for example blog.js) in a text editor and find the function blogPortlet_blogPortlet_doOpenEditor. Located the code line that sets the BasePath location oFCKeditor.BasePath =. The correct choices are:
In addition, based on the consumer application (Portal, or WebCenter) each of the portlets has an init.jsp file (located in each of the portlets samples\webcenter\portlets\[wiki,blog,discussion]\views directory) that must be modified to reflect the path of the fckeditor script file(s). To modify this code, open up the init.jsp and locate the code that sets the rte_path. The correct choices are:
For additional information on the FCKeditor, please visit the following:
Once the portlets have been deployed on the server they must be added to a portal, page, etc. to be used.
Note: For a custom application, when the portlet is added to a page (jspx), you must set the "renderPortletInIFrame" portlet property :
renderPortletInIFrame="true"
The portlets have been designed to be usable by an anonymous (non-authenticated) user, although any customizations made will only be available for the life of the session. When the user authenticates the portlet state will be stored in the portlet preferences, with little need for further manual configuration.
The portlets have been designed to be "bootstrapped" when initially accessed by the user. They will display the configuration screen, allowing the user to enter or select from a list of available options. Example display of configuration screen for Blog Portlet.
NOTE: The first time that a portlet is added to a Portal page, and error may occur when the page is in the "Edit" mode" For example:
The current work around is to click on the "View" mode (exit out of Edit mode).
For configuration details of each portlet please refer to the following links: