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.
The chapter contains the following topics:
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.
Before you decide to use GroupSpace, see Planning and Designing Communities in the Communities Guide to help you determine your Community needs.
The GroupSpace shared J2EE libraries contain the following resources. To see these resources, open the Merged Projects view.
<portalWebProject>/communityFiles/
.<portalWebProject>/framework/skins/
or <portalWebProject>/framework/skins/gsdefault/
.<portalWebProject>/invitations/
.<portalWebProject>/portlets/
.community
extension. Portal administrators use this file to create a GroupSpace Community. Location: <portalWebProject>/<WebContent>/groupspace.community
.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
.Note: | The Page Flow source files used throughout GroupSpace are not available for override. |
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.
After you create your portal application, you can use one of the following methods to enable e-mail-based invitations:
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.communities-config.xml
file in a text editor and customize the information in the following lines, as shown in Listing 4-1.<?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>
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.WebLogic Portal 9.2 domains used the WebLogic Portal GroupSpace Framework Application template to create a GroupSpace database, while Portal 10.0 and later 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 CM Browser portlet displays read-only content from the Shared Content Repository.
Note: | You must install the Portal Examples before you perform these steps. See “Installing the Sample Applications and Domain” in the WebLogic Portal Release Notes for details. |
appsGroupSpaceDataSource
to point to the non-PointBase GroupSpace database you define: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:
<
WLPORTAL_HOME
>/portal/db/oracle/admin/create_tablespaces.sql
and create_users.sql
.<
WLPORTAL_HOME
>/portal/db/sql_server/admin/create_database.sql
.<
WLPORTAL_HOME
>/portal/db/mysql/admin/create_database.sql
<
WLPORTAL_HOME
>/portal/db/sybase/admin/create_devices
and create_database.sql
.<
WLPORTAL_HOME
>/portal/db/db2/admin/create_tablespaces.sql and create_user.sql
.For more details on running these scripts, see the Database Administration Guide
groupspace_database.properties
file to set the database and user information for the GroupSpace Content Management Repository database. 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.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 Oracle supports are available in the following general locations: <
WLPORTAL_HOME
>/portal/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.
<
WLPORTAL_HOME
>/samples/domains/portal/bin/
directory and typing startWebLogic.cmd
. Tip: | To stop the server, change to the < WLPORTAL_HOME >/samples/domains/portal/bin/ directory and type stopWebLogic.cmd . |
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.
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:
.community
file that provides a different configuration of GroupSpace portlets.groupspace.community
file.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.
Modifying certain files could cause GroupSpace to function incorrectly. Do not modify the following GroupSpace resources:
GroupSpace.usr
user profile property set in the <datasync project>/src/userprofiles
directory.Community_Repository/GroupSpace
, Community_Repository/CmxControlUniqueKeysFolder
, Community_Repository/users
..ctmeta
file: callback-class, registration-uri, error-uri, and inviter-invoker-class.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:
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.
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.
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.
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:
See Community Properties Reference for .ctmeta
property descriptions.
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.
Consider the following when modifying Community capabilities:
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.
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.
Perform the following steps to add a GroupSpace control to a Page Flow:
For API-level information on GroupSpace controls, see com.bea.apps.groupspace.*.controls
in
Javadoc.
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.
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.
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.
Use the following guidelines for best performance:
See the Interaction Management Guide for more information on listener classes.
Community properties are set in the following ways:
ctmeta
files that portal administrators use to create Community templates and Communities..portal
files.The following items describe Community properties:
com.bea.apps.groupspace.security.GroupSpaceCallbackImpl
. Your development team may provide its own callback class.
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.
For best performance, use the following guidelines:
web.xml
file.
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).
Choose one of two ways to change the Look & Feel of your GroupSpace Community:
Tip: | Only the GroupSpace Default (gsdefault) Look & Feel is compatible with GroupSpace; you should make all other Look & Feel files (Default, Classic, All Text, and Legacy) unavailable to users. The best way to do this is to create an entitlement role to which that no one belongs, and then entitle the other Look & Feel files so that they are available only to that role. Leave the GroupSpace Default Look & Feel unentitled so that it is available to all users. |
This section contains the following topics:
The following steps describe how to modify one part, the GroupSpace logo, of the default GroupSpace Look & Feel.
Perform the following steps to modify the default GroupSpace Look & Feel:
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.header-logo.gif
file in any image editor, as shown in Figure 4-2. Save your changes.
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:
gsdefault.laf
file..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.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.
Tip: | If you edit your skin.xml file (for example, to import a new CSS file into your new Look & Feel), do not change the skeletonid or skeleton-path. Changing the skeleton can cause it to break; use the gsdefault skeleton that ships with WebLogic Portal. |
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:
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.
Perform the following two steps to enable the rich text editor:
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: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.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.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.<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>
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.You can use portlet preferences to control the rich text editor and the bottom toolbar for individual portlets.
WARNING: | If the web.xml file’s rich text editor values are set to false , any edits you make to portlet preferences in the Administration Console are ignored. If the rich text editor value is false , but the bottom toolbar value is set to true , the toolbar does not appear in the portlet. |
Perform the following steps in the Administration Console to change portlet preferences for rich text editing and the bottom toolbar:
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.
Tip: | By default, rich text editing is not enabled for any of the portlets. |
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.collaboration.max.attachment.size
preference to control the size of mail attachments that users can send or receive.
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.