Oracle® Fusion Middleware Communities Guide for Oracle WebLogic Portal 10g Release 3 (10.3.4) Part Number E14232-02 |
|
|
View PDF |
This chapter describes the concepts and features that make up the Community framework and describes the logic the portal framework uses to render a Community.
This chapter includes the following sections:
This section describes the concepts and features in the Community framework. See also Section 5.11, "Using the Community Framework API."
A Community template is the pre-packaged set of resources from which a Community can be built. A Community template resides in the database and allows business users to create Community applications without any coding.
A .community file is identical to a .portal file in the development environment, but with a different file extension. A .community is a collection of books, pages, portlets, Look & Feel resources, and other components that eventually become a Community. Portal administrators can create Communities directly with a .community file rather than using a Community template.
Another difference between a .community and a .portal file is that the PortalServlet knows how to render a .portal file as a file-based portal. All Communities, however, must be rendered from the database rather than the file system, so the .community file cannot be rendered as a file. For this reason, the PortalServlet does not know how to render a .community file.
The .ctmeta file is an XML file that lets Community developers preconfigure Community properties, such as the .community file that should be used to create the Community, the registration and error page that should be used, and the Community expiration date. The .ctmeta file makes it easy for portal administrators to create portal templates without having to know technical details about the Community configuration.
When a user joins a Community (becomes a member), information is stored in the database that associates the user with the Community. In addition, the member is assigned to a role, or capability, within the Community (such as owner, contributor, or viewer), which can be assigned to the member when the member is invited to join the Community.
Once part of a Community, members have a CommunityUserContext that lets developers set and get membership information about that user within the Community. For information on CommunityUserContext, see the Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal.
Registration is the process by which users join Communities and become members. Registration functionality, represented in a landing web page or portal, can include such operations as authentication, letting users create their Community user names and passwords, and displaying the Communities the members can access.
Communities can be publicly accessible. They do not have to require registration, but a landing page is required when registration is not required.
The WebLogic Portal Visitor Tools, with which users can customize their views of portal desktops, also contain a set of Community tools. The Community tools provide Community management and creation functionality for use in portal applications.
Invitations are the means by which you tell users that they have been invited to join Communities. The Community framework provides the means to send invitations through e-mail using JavaMail, with the ability to extend invitations using formats such as instant messaging.
Notifications are the means by which users communicate with each other in a Community or are alerted to events that occur within a Community. The notification API lets you develop notification functionality in your Communities.
Notifications, which have a limited life span, may come from other users, web applications, or even the framework itself. When notifications are sent, the Community framework persists them in the database until they are consumed or they expire.
Because Communities are designed to serve groups of users with common interests and goals, each Community is scoped to that set of users and has unique characteristics. Community context, represented in the Community framework API, is the collection of Community information, including membership information. Community developers can use Community context to create Community-specific features and functionality. For information on CommunityUserContext, see the Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal.
Users (Community members) also have context within a Community, which can also be accessed and used by Community developers. The CommunityUserContext API lets you get and set member information and perform many types of Community management tasks. For information on CommunityUserContext, see the Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal.
In Community development, you have the option of using capabilities or roles (or both) to control access to Community resources and functionality.
Communities provide a feature called capabilities. For example, the default capabilities for a Community are "creator," "owner," "contributor," and "member." A capability is a text label applied to a Community member and stored in the member's record in the database. (A member can have a different capability in each Community.) The only default security functionality with capabilities is that a Community "creator" can delete a Community, and a Community "owner" can manage a Community. Aside from those two behaviors, capabilities are merely labels. To control access to Community resources and functionality with capabilities, you must get the capability for a member from the CommunityUserContext or ICommunityMemberManager, then set up your security logic on the return value. For information on these Java classes, see the Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal.
For example, if you want to show a button on a page to those only in the Community "owner" role, you would get the current member's capability from the CommunityUserContext or ICommunityMemberManager, followed by the conditional code that shows the button for "owner" and hides it for everyone else.
Roles are widely used in WebLogic Portal. They provide a mechanism for controlling user access to administration tools and portal resources. WebLogic Server lets you create global security roles, and WebLogic Portal lets you create visitor entitlement and delegated administration roles. For example, you can create a portal desktop and designate that it can be viewed only by users in the global "admin" role or the "manager" visitor entitlement role.
In addition, roles are open to auditing, and in your code you can simply use an isUserInRole
method or JSP tag to restrict user access to content or actions.
For Communities, the Administration Console provides a bootstrapping mechanism that creates a default set of Community-specific roles. The default Community roles map to the Community capabilities defined in your application's META-INF/communities-config.xml
file. If you choose to secure your Community resources with these roles, you can simply use the isUserInRole
method/JSP tag to secure Community resources.
If you do not want to use Community roles to secure Community resources, or if you want to use another mechanism as well, you can use capabilities.
For Community development, you must decide whether you want to use capabilities, roles, or both to control access to Community resources and functionality.
The following describes how the portal framework renders a Community. Error code constants are defined in com.bea.netuix.servlets.manager.communities.CommunityRedirectionHelper. For information on CommunityRedirectionHelper, see the Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal.
Is the Community public? Yes: Is the Community active? Yes: Render the Community. No: Redirect to error page with error REDIRECTION_TYPE_COMMUNITY_DEACTIVATED No: Is a user logged in and do they have a membership in the Community? Yes: Is their Community member record active? Yes: Is their Community membership record active? Yes: Is the Community active? Yes: Render Community. No: Redirect to error page with error REDIRECTION_TYPE_COMMUNITY_DEACTIVATED No: Redirect to error page with error REDIRECTION_TYPE_MEMBERSHIP_DEACTIVATED No: Redirect to error page with error REDIRECTION_TYPE_MEMBERSHIP_DEACTIVATED No: Is public registration enabled? Yes: Is a user logged in and do they have a Community member record? Yes: Is the member record active? Yes: Redirect to registration page. No: Redirect to error page with error REDIRECTION_TYPE_MEMBER_DEACTIVATED No: Redirect to registration page. No: Is a user logged in and do they have an invitation to this Community? Yes: Redirect to registration page. No: Redirect to error page with error REDIRECTION_TYPE_NO_PUBLIC_ACCESS