Communities Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Planning and Designing Communities

In the Architecture phase of creating a Community, you determine the type of Community you want to create and plan the resources and functionality you want to be available to the Community. You also determine the properties you want for each Community.

This chapter provides guidance on the factors to consider and activities to perform prior to beginning Community development.

This chapter includes the following sections:


Portal Web Project Facets

If you create a portal web project that is designed for custom Communities, do not include the GroupSpace facets in that web project. GroupSpace Communities need to run in their own portal web projects and cannot be mixed with custom Communities. For more information, see the GroupSpace Guide.


Planning Community Characteristics

Prior to Community development, make decisions about the following Community characteristics. These characteristics, which are set as properties on each Community, can help you determine your Community design:


Determining Security Needs

Decide which roles, or capabilities, you want to provide in your Communities. By default, the Community framework provides “creator” and “owner” capabilities. You can create any others you need, such as “contributor,” “leader,” and so on. Also define the types of operations you want to provide for your capabilities, such as CREATE, VIEW, UPDATE, and DELETE.


Creating Look & Feel Resources

If you want to make Community interface resources, such as Look & Feel files, shells that include the visitor and Community tools, and layouts available to developers before they begin development, create those resources first.

For more information, see the User Interface Development with Look & Feel Features chapter of the Portal Development Guide.


Determining Content Needs

Plan your content needs in advance of Community development.

If you are going to use content management in your Community, whether almost every object is a piece of content or whether you just want document storage, you may find it convenient and secure to create a repository separate from the standard WLP Repository.

Using a separate repository requires a unique data source and tablespace to keep your Community content separate from regular portal desktop content stored in the WLP Repository (or an Oracle-compatible third-party repository). First define your data source by extending your domain with the Configuration Wizard and adding the data source and tablespace to your domain. Later in the staging environment you can configure the new repository to use the new data source.

You can also create a repository and directory structure using a callback class on your Community.

See the Content Management Guide for information on working with content.


Determining Custom Community Property Needs

You can develop Community functionality based on custom Community properties that you expect to be present in Communities. You create custom Community properties—properties that provide unique information about a Community—in the WebLogic Portal Administration Console for a selected Community.

Determine which, if any, custom Community properties you want to create, especially for properties beyond what standard Community properties you can access with the Community framework API (for example, com.bea.netuix.application.communities* and com.bea.netuix.servlets.manager.communities*.

Use the com.bea.netuix.application.communities.CommunityProperty class in conjunction with the CommunityPropertyValue class to get custom Community properties.

See Creating Custom Community Properties for information on creating these properties with the Administration Console.

  Back to Top       Previous  Next