Differences between WebFacing portlet and Web projects

This topic outlines the differences between WebFacing portlet projects and WebFacing Web projects.

When you create a new WebFacing project, you can create a new J2EE 1.3 or 1.4 Struts WebFacing portlet project. You can also add a WebFacing portlet to an existing non-struts based portlet project.

The following lists outline the differences to consider when working with a WebFacing portlet project instead of a WebFacing Web project.
Runtime
  • Portlet projects must be run on a portal server or portal test environment. They cannot be run on a Web application server.
  • The default mode for keyboard text entry is insert mode for portlet projects and it is not configurable in the Project Properties page. The default mode for keyboard text entry is overwrite mode for Web projects and is configurable in the Project Properties page. For both portlet and Web projects, you can toggle insert key to enable either insert mode or overwrite mode for the current page. Only WebFacing Web projects maintain the mode that was selected by the end user on a previous Web page to the next page. Auto tabbing is enabled by default for web project when overwrite mode is configured as default. In WebFacing portlets, auto tabbing is only enabled when you toggle the insert key to enable overwrite mode for the current page.
  • When multiple WebFacing applications are processing an INVITE operation in the portal environment, only one INVITE timer will exist on the portal page. This timer is for the WebFacing application which processed the last request.
  • WebFacing portlet projects do not support the following:
    • Enable Web page compression in the project properties under Run Time > Project.
    • Interoperability with HATS projects.
    • WebFacing application bridge with other Web project such as EGL
Conversion
  • The output of conversion for WebFacing portlet projects is the same as WebFacing Web projects, however, the resulting HTML from the compiled JSPs may differ to allow it to run in the Portal environment.
  • A unique ID setting has been added to enable more than one portlet to run in the same browser. You must follow the same code pattern that is used in the WebFacing JavaScriptâ„¢ functions for Portal to ensure that your Web settings will work for both Web and Portal environments.
  • WebFacing portlet projects are created by default with the conversion option Replace text with button for window records selected in the Project Command Key Recognition properties page. This places buttons in your window records so that they can easily be seen in the compact portal Web page. To enable the same feature in a Web project, you must select the project property, make the change (under Conversion > Command Key Recognition Patterns), save the changes, and then re-convert the project.
Style
  • The main purpose of choosing a WebFacing portlet style is to create a unified look with the portal theme by selecting the style of buttons, window titles, scrollbars, subfile rows, and error messages that you want to display. This is because the style for WebFacing portlet projects is automatically applied with the same look and feel as the style that the administrator of the Portal has chosen. For example, you do not need to change the color of your buttons because they will have the same color as the portal buttons, no matter what WebFacing portlet style you choose. You can still change the color of windows and subfiles using the Project style properties pages, however, this is not the recommended way of modifying WebFacing portlet project styles. To modify the styles of a WebFacing portlet project you can change the Portal style to one of the available styles in Portal or to a user defined Portal style. By contrast, WebFacing Web projects should be modified using the project style properties pages or by editing the apparea.css for all styles.
  • In a WebFacing project, selectors or class names from both the WebFacing (apparea.css) and Portal (Styles.css) style sheets are specified on HTML tags that need to be styled. This allows declarations from both the Portal and WebFacing style sheets to be applied. Since the portal style sheet is imported before the WebFacing style sheet, the latter takes precedence. This means that if the same declaration is specified in both style sheets, the WebFacing declaration will take effect. This is based on the cascading order as defined in the CSS specifications. For example, the following style is applied to a window title:
    <... class="wdwTitleBar wpsPortletAccentArea">Window Title

    For WebFacing portlet projects this will apply the portal theme color when no color is specified in WebFacing style. For WebFacing Web projects the portal style wpsPortletAccentArea is ignored and only WebFacing's wdwTitleBar class is used.

  • For portlet projects, the Project Style Command key property page is not available. To modify the command key style used for your buttons, you must edit the CmdKeys.jsp file located in your portlet project in the WebContent\webfacing\styles\chrome\html\ directory. The class names used to style command keys for WebFacing portlet projects are exclusively from the portal Style.css file. That is the buttonup, buttonover, and buttondown styles are not used to style buttons in WebFacing portlet projects. These have been replaced for the three available WebFacing portlet project styles, 3DButtons, ButtonBar, and ClickLinks.
  • The styles available for WebFacing portlet projects differ from those for WebFacing Web projects. A WebFacing Web style cannot be used in a WebFacing portlet project and a style for a portlet project cannot be used in a WebFacing Web project.

Feedback