2 Determining Community Needs

This chapter helps you determine when to create a Community and when to create regular portal desktops.

This chapter includes the following sections:

Section 2.1, "Do You Need Communities?"
Section 2.2, "Creating a Custom Community"
Section 2.3, "Where to Go Next"

2.1 Do You Need Communities?

Use the following table to determine if you need to develop a Community or if you should develop a portal desktop.

If you need…	Communities provide…
Tools to have portal features behave differently, depending on Community role For example, you have internal administrators and partner administrators for partner Communities. You need some additional functionality for internal administrators that partner administrators will not see.	Granular Community context The Community framework provides Community context information so that you can determine if a user is a member of a certain Community and the role that the user has in the Community. Given these combinations, you can have different functionality available in the same portlet. With regular portal desktops, you can control user access to resources as well. For example, you can use entitlements to control which books, pages, and portlets users see; and you can use the security API and JSP tags to control access to inline content based on security roles. However, assigning users to roles either involves heavy manual, centralized, and always-available portal management, or the development of role-assigning functionality that can be difficult to create and maintain. Communities are advantageous in this case, because Community administrators can assign Community roles to their own members, and the Community gives developers a richer set of information for developing programmatic access to resources.
Custom portal member roles For example, your partner Communities need a number of custom member roles that are constrained to certain application functionality. For example, you need a role for your dealers that lets them administrator information but only view other information.	Custom Community roles Using the Community framework, you can define custom roles. These roles are defined in XML and are available within the Community management tools to target capabilities to roles. In regular portal desktops, you only grant or deny access to resources. With Communities, you can control the exact type of access end-users have. For example, some Community users are able to create, edit, and delete content, while other users are allowed to only view content.
To enable others to create custom Communities For example, you built a custom Community for your distributors and now the distributors want to use very similar capabilities in Communities for their resellers. However, there are potentially thousands of Communities for these dealers.	Community templates The Community framework includes the ability to create a Community template that includes whatever resources (portlets) you want to include, and roles you define. This template can be used by non-technical end-users to create a new Community. Regular portal desktops provide no capabilities for end-users to create and manage their own desktops.

If you need…

Communities provide…

Tools to have portal features behave differently, depending on Community role

For example, you have internal administrators and partner administrators for partner Communities. You need some additional functionality for internal administrators that partner administrators will not see.

Granular Community context

The Community framework provides Community context information so that you can determine if a user is a member of a certain Community and the role that the user has in the Community. Given these combinations, you can have different functionality available in the same portlet.

With regular portal desktops, you can control user access to resources as well. For example, you can use entitlements to control which books, pages, and portlets users see; and you can use the security API and JSP tags to control access to inline content based on security roles. However, assigning users to roles either involves heavy manual, centralized, and always-available portal management, or the development of role-assigning functionality that can be difficult to create and maintain.

Communities are advantageous in this case, because Community administrators can assign Community roles to their own members, and the Community gives developers a richer set of information for developing programmatic access to resources.

Custom portal member roles

For example, your partner Communities need a number of custom member roles that are constrained to certain application functionality. For example, you need a role for your dealers that lets them administrator information but only view other information.

Custom Community roles

Using the Community framework, you can define custom roles. These roles are defined in XML and are available within the Community management tools to target capabilities to roles.

In regular portal desktops, you only grant or deny access to resources. With Communities, you can control the exact type of access end-users have. For example, some Community users are able to create, edit, and delete content, while other users are allowed to only view content.

To enable others to create custom Communities

For example, you built a custom Community for your distributors and now the distributors want to use very similar capabilities in Communities for their resellers. However, there are potentially thousands of Communities for these dealers.

Community templates

The Community framework includes the ability to create a Community template that includes whatever resources (portlets) you want to include, and roles you define. This template can be used by non-technical end-users to create a new Community.

Regular portal desktops provide no capabilities for end-users to create and manage their own desktops.

If you do not need any of those Community-specific features, create regular portal desktops. See the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.

2.2 Creating a Custom Community

In developing a custom Community, you must develop Community functionality from the ground up: invitation and notification mechanisms, registration, content management configuration, error handling, and application functionality (which includes controlling application behavior based on the security capabilities you define; for example, letting Contributors create content and Viewers only view content).

WebLogic Portal provides a set of Community management tools, which are included in the visitor tools, that let Community administrators create Communities, modify Community properties, configure security rights, and assign security rights to Community members, and let Community members view the Communities to which they belong.

WebLogic Portal also provides a predefined set of collaboration portlets for calendar, mail, tasks, discussion forums, and storing contacts. Inside a Community, the Calendar, Address Book, and Tasks portlets automatically provide Personal and Community tabs for creating items that only that user can see and items that the entire Community can see.

2.3 Where to Go Next

If you decided to create a custom Community, continue with this guide.
If you decided to create a regular portal desktop, see the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.