Planning and Designing Communities

In the Architecture phase of creating a Community, you determine the types 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 characteristics you want for each Community.

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

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:

Whether or not anyone can access the community without registering as a member.
Whether or not anyone can register as a member in the community without first receiving an invitation.
What will serve as the registration or landing page for a community, and how it should function (especially in light of the decisions you make on the previous properties).
Whether or not you want to provide the visitor tools for community members to customize their own views of a community.
What will serve as 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. Also determine how you want that page to behave. For more information, see "Developing a Multi-Purpose Community Error Page" in the Developing Custom Communities chapter.
Whether or not (and when) the community will automatically become inactive or expire.
Whether or not you want to track the number of times members visit the community is stored in the virtual content repository.
What, if anything, you want to happen automatically when communities are created, activated, deactivated, or deleted. For example, if you want a community content repository to be created when a community is created. You build this type of functionality in a callback class. For more information, see "Developing Callback Classes" in the Developing Custom Communities chapter.

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, READ, UPDATE, and DELETE.

Creating Look & Feel Resources

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

Determining Content Needs

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 BEA 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 BEA Repository (or a BEA-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.

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; in particular, 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" in the Creating and Managing Communities chapter for information on creating these properties with the WebLogic Portal Administration Console.

Communities Guide