Working with GroupSpace in Development

Working with a GroupSpace Community in the development phase involves enabling e-mail-based invitations and performing other optional development tasks to extend a GroupSpace Community.

Creating a GroupSpace Community

Creating a GroupSpace Community is ultimately performed by a portal administrator in the Administration Console, or by a GroupSpace end user with appropriate rights. GroupSpace Communities, like all Communities, are rendered from the database (rather than the file system). In order to create a GroupSpace Community, those administrators and users rely on resources that are accessible from the development environment.

Development tasks are not required for administrators and end users to create default GroupSpace Communities. There are primary resources involved in the creation of GroupSpace Communities—resources that developers can extend or modify as needed.

Understanding GroupSpace Resources

The GroupSpace shared J2EE libraries contain the following resources. To see these resources, open the Merged Projects view.

Shell – A Community shell containing the Visitor and Community Tools. GroupSpace uses this shell and applies look and feel overrides to give the header its appearance. Location: <portalWebProject>/communityFiles/.
Look and Feel – A default GroupSpace Look and Feel. Location: <portalWebProject>/framework/skins/ or <portalWebProject>/framework/skins/gsdefault/.
Invitation – The invitation e-mail that is sent to Community invitees. Location: <portalWebProject>/invitations/.
Portlets– The GroupSpace and Collaboration Portlets. Location: <portalWebProject>/portlets/.
The groupspace.community file – A portal file with a .community extension. Portal administrators use this file to create a GroupSpace Community. Location: <portalWebProject>/<WebContent>/groupspace.community.
The groupspace.ctmeta file – A Community template metadata file that provides preconfigured settings for the default GroupSpace Community. This file is used to create a a Community template and a Community, and references the .community file to use to create the Community. The file also contains advanced settings that make Community template creation easy for portal administrators. Location: <portalWebProject>/<WebContent>/groupspace.ctmeta.
The communities-config.xml file – This enterprise application-level file lets you configure the e-mail settings for your e-mail server (to send Community invitations) and lets you add security capabilities to your Communities.

You can use these resources without modification in order to create default GroupSpace Communities, or you can develop customizations to configure your own version of GroupSpace. For information on customizations you can make, see Extending the Default GroupSpace.

Enabling E-Mail-Based Invitations

After you create your portal application, you can use one of the following methods to enable e-mail-based invitations:

Launch your GroupSpace Community and use the following steps in the UI to configure e-mail invitations:

Log into your GroupSpace Community.
Choose Communities > Manage This Community.
On the Properties Page tab, click Community Email Configuration.
In the Reply-to Address field, enter your e-mail address.
In the Display Name, enter the name you want to appear in the From field in your e-mails.
In the Outgoing Mail Server (SMTP) field, enter the outgoing host name or IP address.
In the Outgoing Mail Port (SMTP) field, enter the port number to connect to the outgoing mail server. For example, enter 25 for SMTP.
In the Account username (SMTP) field, enter the name of your mail account. Do not use special characters.
In the Account passsword (SMTP) field, enter a password.
Click Save.

You can also manually configure e-mail invitations by locating the communities-config.xml file in the \META-INF directory of your EAR application and editing it. For example, C:\Documents and Settings\dsmith\workshop\myportalEAR\META-INF. If you do not have a communities-config.xml file, you must create one by copying Listing 4-1 to a text file.

Open the communities-config.xml file in a text editor and customize the information in the following lines, as shown in Listing 4-1.

Listing 4-1 Enter Your Values in the communities-config.xml File

<?xml version="1.0" encoding="UTF-8"?>
<communities-config xmlns="http://www.bea.com/ns/portal/ 90/communities-config">
     <properties-config>
          <property-map>
               <name>groupspace.DefaultEmailConfiguration</name>
               <property>
                    <name>replyToAddress</name>
                    <value>--Please Change-- some.user@
                         yourcompany.com</value>
               </property>
               <property>
                    <name>displayName</name>
                    <value>GroupSpace Emailer</value>
               </property>
               <property>
                    <name>smtpServer</name>
                    <value>--Please Change-- smtp.yourdomain.com</value>
               </property>
               <property>
                    <name>smtpPort</name>
                    <value>25</value>
               </property>
               <property>
                    <name>smtpUsername</name>
                    <value>--Please Change-- smtpuserid</value>
               </property>
               <property>
                    <name>smtpPassword</name>
                    <value>--Please Change-- smtppassword</value>
               </property>
          </property-map>
     </properties-config>
</communities-config>

Save the communities-config.xml file. You can change these settings later in your GroupSpace Community by choosing Communities > Manage This Community and selecting the Properties Page tab. You can change these settings for each GroupSpace instance.

Note:

If you plan to run the sample GroupSpace application, the database is already configured. By default, all domains are configured to use PointBase.

Configuring the Database in a New Domain

WebLogic Portal 9.2 domains used the WebLogic Portal GroupSpace Framework Application template to create a GroupSpace database, while Portal 10.0 domains use the WebLogic Portal GroupSpace Application Collaboration Repository. See Adding GroupSpace to Your Portal Domain for more information.

If you created a new domain or extended an existing domain with the Configuration Wizard, you can use a database other than PointBase. PointBase is the default database. The items you create in the GS Example Community are stored in the GroupSpace database. The CM Browser portlet displays read-only content from the Shared Content Repository.

Perform the following steps to add GroupSpace content repository database objects, and then add and configure an appsGroupSpaceDataSource to point to the non-PointBase GroupSpace database you define:

If the WebLogic Server and the WebLogic Portal Administration Console are running, stop them.
Back up your database data as described by your database vendor.
For new 10.0 domains, the WEBLOGIC_GROUPSPACE schema is automatically created within the default PointBase database. The appsGroupSpaceDataSource is automatically added to the new domain and configured to access the WEBLOGIC_GROUPSPACE schema. GroupSpace database objects must reside in a different database schema than the main portal database objects (which were created in the WEBLOGIC PointBase schema by default).

For a PointBase database, go to step d. For the following types of databases, a Database Administrator must define a database user or database for the WebLogic GroupSpace database schema:

For Oracle, see <WLP_HOME>/db/oracle/admin/create_tablespaces.sql and create_users.sql.
For SQL Server, see <WLP_HOME>/db/sql_server/admin/create_database.sql.
For mySQL Server, see <WLP_HOME>/db/mysql/admin/create_database.sql
For Sybase, see <WLP_HOME>/db/sybase/admin/create_devices and create_database.sql.
For DB2, see <WLP_HOME>/db/db2/admin/create_tablespaces.sql and create_user.sql.

For more details on running these scripts, see the Database Administration Guide

Edit the domain's groupspace_database.properties file to set the database and user information for the GroupSpace Content Management Repository database.
You can use the BEA WebLogic Configuration Wizard (see the BEA Products Creating WebLogic Domains Using the Configuration Wizard Guide for detailed instructions) or run create_db.cmd -database.properties=groupspace_database.properties from the domain's home directory (or . ./create_db.sh -database.properties=groupspace_database.properties) to add the GroupSpace database objects.
After you define a non-PointBase database in a new 9.x domain, you can replace the appsGroupSpaceDataSource (which points to PointBase by default) in your domain with the one from the appropriate driver directory, and then update it for your database environment. Manually edit the @CMREPO_DB...@ variables for the database you configured in step c. Sample appsGroupSpaceDataSource-jdbc.xml definition files for each database and driver that BEA supports are available in the following general locations: <WLP_HOME>/db/jdbc/<database_driver>. For example, oracle_bea or sybase_bea.

For more details on setting up your GroupSpace database, see the Database Administration Guide.

Start the server by changing to the /<WEBLOGIC_HOME>/samples/domains/portal/bin/ directory and typing startWebLogic.cmd. You can view the GS Example Community, which is populated with sample data, at http://<localhost>:7041/groupspace/ groupspace.jsp. The CM Browser portlet uses the Shared Content Repository; all other data is stored in the Community Repository.

After you create a portal, the next step is to create a Community template. A Community template is a packaged set of resources that you can use to build a project management or collaboration application. You can create a Community template and use that template to create a new Community without writing additional code. See Creating a GroupSpace Community Template for instructions on creating a GroupSpace Community template.

After you create a GroupSpace template in the Staging phase, you can propagate that template to the production environment where it can be used to create GroupSpace Communities.

Extending the Default GroupSpace

The default GroupSpace template and resources let you quickly and easily create a full-featured GroupSpace Community. However, there might be times when you want to modify the default GroupSpace template. For example:

Extending a GroupSpace Community could also involve adding functionality. For example:

The following sections describe some of the ways you can extend the default GroupSpace Community template.

Understanding Which Files to Not Modify

Modifying certain files could cause GroupSpace to function incorrectly. Do not modify the following GroupSpace resources:

Copying Source Files from the Library

If you want to modify resources used in GroupSpace, copy those resources from the shared library. When you copy resources from a library to your file system, the file system copies take precedence over the library resources.

Perform the following steps to copy GroupSpace resources from the shared library:

Switch to Merged Projects view (included with the Portal perspective).
Right-click any available shared library resources (they appear in italic font), and select Copy to Project.
Switch to the Navigator view and open the resources for modification.

To return to using the shared library versions of any files, delete the files from the Navigator view. Before you delete a file, verify that it is a file that is stored in the shared library. Some files provided in GroupSpace are not included in the shared library and will be permanently deleted if you delete them in the Navigator view.

Changing the Text of the GroupSpace Invitation E-mail

If you want to modify the e-mail text that is sent for invitations to a Community, modify the /invitations/email/invite_body.jsp and invite_subject.jsp files.

When you modify either of these files, you must restart the server for the changes to take effect.

Modifying the groupspace.community File

The groupspace.community file, located at <portalWebProject>/<WebContent>/groupspace.community, is a portal file with a .community extension. It contains the full set of GroupSpace features and can be used as is for creating GroupSpace Communities.

You can modify this file to suit your needs. For example, if you do not want the Mail portlet to be included in GroupSpace Communities that are created from this file, you can remove the portlet in the portal editor.

However, modify this file only for simple changes. If you want to make major modifications to this file, make a copy of it or create a new Community file and make more extensive modifications to it.

Modifying the groupspace.ctmeta File

The groupspace.ctmeta file, located at <portalWebProject>/<WebContent>/groupspace.ctmeta, is a Community template metadata file that provides default settings (many of them advanced) for a Community template. Portal administrators use this file to quickly and easily create Community templates, which in turn are used to create Communities that have those settings. Among other settings, this file specifies groupspace.community as the .community file that is used for the Community.

You can modify this file to suit your needs. For example, if you create a new .community file that you want to use as a basis for new Communities, you can reference that file in the .ctmeta file.

If you want to retain the original groupspace.ctmeta file, you can make a copy of the groupspace.ctmeta file or create your own .ctmeta file.

You can change any settings in this file. However, for GroupSpace to work correctly, do not change any of the following properties:

Modifying GroupSpace Security Capabilities

GroupSpace provides the following security capabilities, or role names: creator, owner, contributor, and viewer. (Creator and owner are provided by default in every Community, even non-GroupSpace Communities.) GroupSpace uses these capabilities to control create, read, update, and delete actions performed by users in GroupSpace.

These capabilities are defined in the /META-INF/communities-config.xml file in the GroupSpace shared library. You cannot modify this file. However, you can add capabilities to your <portalEARproject>/META-INF/communities-config.xml file and develop custom functionality that uses those capabilities.

Users with Community management rights can also override capability rights in the Community Tools. For example, a Community administrator can add “update” rights to viewers. The updated capability settings are stored in the database.

A GroupSpace Community defines rights for each of its default capabilities: creator, owner, contributor, and viewer. If you modify any of the rights for a capability in the Community Tools, those rights modifications are stored in the database and override the default rights.

Using GroupSpace Controls

GroupSpace provides many convenience controls that you can add to your Page Flows. These controls let you develop many types of GroupSpace functionality and provide powerful search capabilities.

Open the Page Flow controller and switch to the Page Flow Explorer view (available in the Page Flow perspective).
Right-click Referenced Controls and choose Add Control.
In the Select Control window, expand the appropriate Portal GroupSpace controls group, select the control you want to use, and click OK.
The control appears under Referenced Controls, where you can expand it and drag the actions you want into the page flow.

For API-level information on GroupSpace controls, see com.bea.apps.groupspace.*.controls in Javadoc.

Using the GroupSpace API

GroupSpace provides a rich API for developing custom GroupSpace functionality. Functionality developed using the GroupSpace API can be used only in the context of a GroupSpace Community. For example, if you develop custom GroupSpace RSS portlet using the com.bea.apps.groupspace.rss.feed.Feed class, that portlet will not work in a non-GroupSpace Community.

For details on the GroupSpace API, see the com.bea.apps.groupspace.* packages in Javadoc.

Adding Your Own Community Portlets

You can add custom-built portlets to your GroupSpace Community. Develop a portlet that contains the functionality you want, using such resources as the GroupSpace controls and the Community framework API, then add the portlet to the .community file to which you want it to belong.

Any portlet you develop using the Community framework API can run only in the context of a Community. Likewise, any portlet you develop using the GroupSpace API can run only in the context of a GroupSpace Community.

Using GroupSpace Events

GroupSpace includes many predefined events that are automatically triggered as users interact with a GroupSpace Community. As each event is fired, the event is added to a buffer by a predefined event listener. When the buffer is flushed to the database, the count for each type of event that has occurred is updated. GroupSpace tracks only the number of times each type of event occurred.

GroupSpace automatically tracks create, read, update, and delete operations on GroupNotes, Links, Doc Library, Issues, and RSS channels. GroupSpace does not currently track: Links, view and delete; Doc Library, create and update; and RSS channels, view.

The counts are stored in Community_Repository\Groupspace\<AppName>\<WebApp>\<CommunityName>\groupspace\ Analytics\ <EventName>. For example, \Groupspace\myPortalEAR\ myPortalWebProject\myGroupSpace\groupspace\Analytics\ LoginEventx295rf29v6ljstcmjryfey3dhysvdlo. You can use WebLogic Portal's content management API to access the event counts for your own analytical purposes.

The event listener (com.bea.apps.groupspace.analytics.listeners. AnalyticEventListener) is registered as an asynchronous listener in the Administration Console. Choose Configuration & Monitoring > Service Administration. Expand the Personalization folder and select Event Service. If you want to stop tracking event counts, you can unregister the listener.

Community Properties Reference

Title – The default name of the Community that appears in the user interface. The title can be overridden by the localized Community title.
Description – The default description of the Community that appears in the user interface. The description can be overridden by the localized Community description.
Allow non-members to access this community – If set to true (checked), anyone can access the Community without registering as a member.
Allow anyone to register for community membership – If set to true (checked), anyone can register as a member in the Community without first receiving an invitation.
Allow people to customize their view and add personal pages – If set to false (unchecked), the Visitor Tools are disabled in the Community. Community administrators, however, can still access the Community Tools.
Registration Uri/Page – The path to the Community registration page, usually the home page for a Community.
Error Uri/Page – The path to the error page that is displayed when a user is not allowed access a Community; for example, if the user is not a member or the Community is disabled.
Expiration Date - The date when the Community will automatically become inactive.
Make this community active now / Status – If set to Inactive, only Community members with an administrative capability can access the Community.
Track member visits to this community – If set to yes, the number of times members visit the Community is stored in the virtual content repository.
Callback Class – The name of the class (including the package path information) that performs special tasks when the Community is created, activated, deactivated, or deleted. For example, the GroupSpace callback class is com.bea.apps.groupspace.security.GroupSpaceCallbackImpl. Your development team may provide its own callback class.
Enable Tree Optimization – If set to true, improves Community performance. For more information on this feature, see Designing Portals for Optimal Performance in the Portal Development Guide.

Analyzing GroupSpace Events

A GroupSpace Community includes several predefined events that are automatically triggered as users interact with a GroupSpace Community. As each event occurs, the event is captured by a predefined event listener and stored in a buffer. When the buffer information is written to the database, the count for each type of event that occurred is updated.

The events are not visible in the UI, but you can view and analyze the events later. The ability to capture and store events is on by default, and these events must occur within a GroupSpace Community.

GroupSpace Community events automatically track the following create, read, update, and delete operations for the portlets listed in Table 4-1

The events are asynchronous events and are stored in the Community Repository in the following location: \Community_Repository\Groupspace\<AppName>\<WebApp>\ <CommunityName>\Analytics\<EventName>. For example, \Groupspace\myPortalEAR\ myPortalWebProject\myGroupSpace\Analytics\LoginEventx295rf29v6ljstcmjryfey3dhysvdlo. You can use WebLogic Portal's content management API to access the event counts for your own analytical purposes.

The pre-configured event listener (com.bea.apps.groupspace.analytics.listeners. AnalyticEventListener) is registered as an asynchronous listener in the Administration Console. (Choose Configuration & Monitoring > Service Administration, and then expand the Personalization folder and select Event Service.)

The event listener is located in the p13-config.xml file. If you want to stop tracking event counts, you can unregister the listener. The event information that is stored for each Community is the event name, the count, and the date. See the Interaction Management Guide for more information on listener classes.

Changing the GroupSpace Look & Feel

Look & Feel determines the appearance of your GroupSpace Community, from the placement and behavior of elements on a page to the colors used in the portlet title bars.

A Look & Feel file (.laf) is an XML block that is inserted into the overall .portal XML file. The Look & Feel file references a specific skin and skeleton. The skin provides a set of images, JavaScript functions, and CSS files, which are referenced by the skeleton JSPs that convert the portal XML components to the final HTML output. See the Portal Development Guide for more detail on Look & Feel, skins, and skeletons.

WebLogic Portal ships with several different Look & Feel files that do not work within a GroupSpace Community. This is due to implementation details of the A GroupSpace Community is tightly coupled with the GroupSpace custom Look and Feel (gsdefault).

Modify the existing Look & Feel by overriding what is provided in the library modules
Create a new Look & Feel by duplicating the default GroupSpace Look & Feel and editing it. This method leaves the original Look & Feel, unless you block it with entitlements.

Modifying the Default GroupSpace Look & Feel

The following steps describe how to modify one part, the GroupSpace logo, of the default GroupSpace Look & Feel.

In WorkSpace Studio, verify that the Visitor Tools project facet is installed in your portal web project. See Enabling Visitor Tools in the Portal Development Guide for instructions on enabling a new Look & Feel.
Choose Window > Show View > Merged Projects. The Merged Projects view provides a virtual view of your project where items in italics are located in the library modules that ship with WebLogic Portal, and other items physically reside in your project directory. Items in your project directory will be used instead of library module items if they have the same name and path. WebLogic Portal provides the ability to create an overriding local copy of a file from a library module.
Expand the following italicized directories in your portal web project directory: framework > skins > gsdefault > images, as shown in Figure 4-1.

Figure 4-1 The images Directory

The images Directory

For example, right-click the italicized header-logo.gif file in the /images directory and choose Copy to Project. The item is no longer italicized because your project has a local copy of the file that will be used instead of the library module version.
Right-click your copy of the file and choose Properties to see where the file is located on your local disk, or right-click the file and choose Show In > Navigator to see the local file in an unmerged view of your project.
Edit your local copy of the header-logo.gif file in any image editor, as shown in Figure 4-2. Save your changes.

Figure 4-2 Edit the header-logo.gif File

Edit the header-logo.gif File

Access the GroupSpace Community in your browser to view the changes. If you do not see the changes, the old image may be cached by the browser. Refresh your browser to reload all the images and the CSS.
Perform these same steps to modify other Look & Feel and CSS files. Be careful changing these files as edits can affect other functionality in your GroupSpace Community. Test your changes often.

Creating a New GroupSpace Look & Feel

You can create a new GroupSpace Look & Feel based on the default gsdefault.laf file. (See the Portal Development Guide for instructions on creating other new Look & Feel files.)

Perform the following steps to duplicate the entire GroupSpace Default Look & Feel and edit it to create your own Look & Feel:

Verify that the Visitor Tools project facet is installed in your portal web project. See Enabling Visitor Tools in the Portal Development Guide for instructions on enabling a new Look & Feel.
In the Merged Projects View, expand the /framework/skins directories so you can see the /gsdefault directory.
Right-click the /gsdefault directory and choose Copy to Project.
On your local disk, rename the gsdefault directory (under your project's /framework/skins directory) to a new Look & Feel name. Do not use spaces in the name.
In the Merged Projects View, expand the /framework/markup/lookandfeel directories so you can see the gsdefault.laf file.
Right-click gsdefault.laf and choose Copy to Project.
On your local disk, rename the gsdefault.laf file (in your project's framework/markup/lookandfeel directory) to match your new Look & Feel name from step 4.
Edit your new .laf file: change the title, description, definitionLabel, markupName (to match the definitionLabel), and skin (to match the name in step 4 & step 7) and save your changes. Do not change the skeleton, skeletonPath, or skinPath.
Redeploy the application and restart the server to see your new Look & Feel. The new Look & Feel should be available in the Customize > Colors menu in your GroupSpace Community.
Edit the images and CSS in your new /skin directory to make changes.

The skin also references the CSS and images in the /<yourproject>/wlpAppsCollaborationCore directory. You may want to make local copies of certain files there, or the whole directory. Javascript exists in the directory; take care if you decide to replace the entire directory with a renamed directory, rather than just overriding certain files.

Setting Up the Rich Text Editor

Some GroupSpace portlets have a rich text editor to apply formatting to documents or other items. Portal Administrators can allow users to access a portlet’s formatting toolbar and a bottom toolbar, which lets them view the item’s HTML text or preview the item.

For example, enabling rich text editing in the GS Issues portlet allows users to use the formatting toolbar to apply bold, Italic, indentations, colored fonts, and so on. Enabling the bottom toolbar in the GS Issues portlet lets users see and use the HTML, Edit, and Preview buttons.

You can enable or disable the rich text editor settings for the following portlets:

Enabling Rich Text Editing

The GS Example Community has the rich text editor enabled by default and the bottom toolbar disabled. For all other web applications, the System Administrator must edit the web.xml file to enable the rich text editor and the bottom toolbar, and then the Portal Administrator sets the portlet preferences.

The System Administrator uses a text editor to edit the web.xml file in your /WEB-INF directory and add the required context parameters and values, as shown in Listing 4-2. After you edit the file, restart the WebLogic server. Use the following guidelines to determine how to set the values in the web.xml file:

If the rich text editor (RichTextEditorEnabled)value is set to false in the web.xml file, rich text editing is not enabled and the bottom toolbar is not enabled and does not appear in the portlet. You cannot override the settings in the Administration Console, as described in step 2.
If the bottom toolbar (RichTextEditorHTMLToolBarEnabled) value is set to false in the web.xml file, and the rich text editor value is set to true, rich text editing is enabled, but not the bottom toolbar. The bottom toolbar does not appear in the portlet. You cannot override the bottom toolbar settings in the Administration Console.
If the bottom toolbar value is set to true but the rich text editor is set to false, the bottom toolbar is not enabled and rich text editing is not enabled. You cannot override the settings in the Administration Console.

Listing 4-2 Add Context Parameters and Values to the End of the web.xml File

<context-param>
     <param-name>com.bea.apps.groupspace.RichTextEditorEnabled</param-name>
    <param-value>true</param-value>
</context-param>

<context-param>
    <param-name>com.bea.apps.groupspace.RichTextEditorHTMLToolBarEnabled
         </param-name>
    <param-value>true</param-value>
</context-param>

<context-param>
    <param-name>collaboration.RichTextEditorEnabled</param-name>
    <param-value>true</param-value>
</context-param>

After the context parameters are added to the web.xml file, the Portal Administrator uses the Administration Portal to modify portlet preference settings for each portlet. See Modifying Portlet Preferences for Rich Text Editing.

Modifying Portlet Preferences for Rich Text Editing

You can use portlet preferences to control the rich text editor and the bottom toolbar for individual portlets.

Perform the following steps in the Administration Console to change portlet preferences for rich text editing and the bottom toolbar:

In the Administration Console, choose Portal > Portal Management.
In the Portal Resources tree, expand the Library folder and the Portlets folder.
Click Next or Prev to locate the portlet you wish to modify and select it so that it is highlighted, as shown in Figure 4-3.

Figure 4-3 Select the Portlet Whose Preference You Want to Modify

Select the Portlet Whose Preference You Want to Modify

After you select the portlet, click Portlet Preferences.
Locate the preference you want to change, as shown in Figure 4-4.

Figure 4-4 Click Edit to Change a Preference

Click Edit to Change a Preference

The GS Issues, GS GroupNotes, and GS Announcement portlets contain a preference called RichTextEditorEnabled. Verify that the preference’s setting is true, to allow the portlet to display the rich text editor. If this preference is set to any value other than true, the portlet displays a simple text area for entering information. Other portlets (Address Book in Contacts, Mail, Calendar, Tasks and Discussion Forums), also have preferences to enable the rich text editor, but they are named differently that the GS portlets. After you locate the portal preference you want to change, click Edit.

Select the Is Modifiable check box for the RichTextEditorEnabled preference to allow users to modify this preference. Do not select the Is Multi-valued check box. Click Save.

Figure 4-5 The Rich Text Editor in a Portlet

The Rich Text Editor in a Portlet

Tip:

By default, the GS Example Community that ships with WebLogic Portal has the rich text editor formatting toolbar enabled, and the bottom toolbar is disabled. For other web projects, the default is that rich text editing is not enabled for any of the portlets.

You can also change the preference that controls the display of the bottom toolbar. For example, if you change the GS Issues RichTextEditorHTMLToolBarEnbled preference to true, the portlet displays the bottom toolbar when the rich text editor is available. The toolbar controls the Edit, HTML, and the Preview buttons. Clicking HTML allows a user to enter HTML directly into the text area. See Figure 4-6.

Figure 4-6 The Bottom Toolbar in a Portlet that Allows Rich Text Editing

The Bottom Toolbar in a Portlet that Allows Rich Text Editing

Other portlets might contain other preferences that you can set. For example, the Mail portlet has a collaboration.max.attachment.size preference to control the size of mail attachments that users can send or receive.
After making your changes to the portlet preferences, click Save to see the change appear in your portlet in your Community desktop. If you made preference changes at the library level, click Propagate to Instances to force proliferation of this preference to every instance of this portlet. WebLogic Portal overwrites all desktop instance’s preferences with the library preferences. For more information on propagating to instances, see the Portlet Development Guide.

Searching for Microsoft Word, Excel, and PowerPoint Files in Multibyte Languages

You can configure search and indexing for Microsoft Word (.doc), Excel (.xls), and PowerPoint (.ppt) files in Content Management and GroupSpace communities. For information on how to do this see “Enterprise Search for Microsoft Word, Excel, and PowerPoint Files in Multibyte Languages” in Multi-language Searching and Indexing in Integrating Search.

	Create	Read	Update	Delete
GS Links		X		X
GS Document Library	X		X
GS Issues
GS RSS Reader		X
GroupNotes

GroupSpace Guide