|Copyright © 2000, 2008, Oracle and/or its affiliates. All rights reserved.|
|PREV PACKAGE NEXT PACKAGE||FRAMES NO FRAMES|
|CommunityCallback||Defines callback methods that the WLP framework makes in response to various community lifecycle events.|
|AbstractCommunityCallback||AbstractCommunityCallback - default implementation of the
|CommunitiesConfigProperties||Represents a set of properties which have been configured via communities-config.xml.|
|CommunityDesktop||CommunityDesktop - specifies the desktop to be used to create a community.|
|CommunityInfo||A structure to pass information to the
|CommunityMember||Represents a single
|CommunityMembership||CommunityMembership - value object class that contains information
about a membership of a
|CommunityMembershipCriteria||The CommunityMembershipCriteria object is used to specify attributes used to find specific CommunityMembership objects from a particular community.|
|CommunityProperty||Represents a property associated with a community.|
|CommunityPropertyValue||CommunityPropertyValue contains a value for a community property.|
|CommunitySearchCriteria||CommunitySearchCriteria - search criteria for communities.|
|MemberCriteria||The MemberCriteria object is used to specify a member to search for.|
|MemberMembershipCriteria||The MemberMembershipCriteria object is used to specify attributes used to find specific CommunityMembership objects for a particular user.|
|MembershipCapability||Represents a Capability that has been granted to a
|MembershipCriteria||The MembershipCriteria object is used to specify attributes used to find specific CommunityMembership objects.|
CommunityDefinitionobject. The CommunityDefinition stores attributes about a community instance which apply to the entire community, such as whether a community requires users to be members of the community to view it. For a full discussion of community attributes, see the CommunityDefinition Attributes documentation below.
CommunityMemberobjects, which represent a link between users in WebLogic Server and the community framework. Each WLS user may have zero or one CommunityMember objects; if the user has never participated in any communities they may not have a CommunityMember object, but if they are to participate in a community as a community member, a CommunityMember object must be created for them. For a full discussion of CommunityMember attributes, see the CommunityMember Attributes documentation below.
CommunityMembershipobjects which represent the set of users (CommunityMembers) within the community. A single user may have at most one CommunityMember object associated with them, but they may have many CommunityMembership objects- one per community in which they are a member. For a full discussion of CommunityMembership attributes, see the CommunityMembership Attributes documentation below.
CommunityContextobjects, which surface most community framework functionality and provide access to other helper classes. The CommunityUserContext serves as a cache container and accessor for community member information (community-specific user information shared across all communities) for a
HttpSessionand provides access to community API's out of scope of a specific CommunityContext object (methods not dealing with the currently authenticated principal, and community creation). The CommunityContext object serves as a cache container and accessor for community and membership information for a
HttpSession, for a single community. Both CommunityContext and CommunityUserContext objects may generally be obtained at the servlet level via convenience methods that use the current
HttpServletRequest. Context instances obtained in this manner should never be kept via references or set into request or session attributes, as these references can end up existing across requests, and the context objects maintain an internal reference to the request they were obtained on, which can result in runtime errors. Instead, whenever one of these context objects is needed, it should be obtained directly from the current request using one of the convenience methods.
CommunityDefinitionobject determines how a community is configured within the portal framework, and has the following major configurable attributes:
|accessTrackingEnabled||boolean||If this attribute is
||The fully-qualified class name of an optional class which receives callbacks from the portal framework when the community
instance is created, destroyed, activated or deactivated. The class must implement the
||A description of the community.|
||A URI to an error page for this community, which is displayed if there is an error accessing the community. There are many different cases where a user may be redirected to this error page, such as if the community is deactivated or the user does not have permission to access the community; for more information see the discussion of Community Error Pages.|
||An optional date and time when the community will automatically
be deactivated by the framework. In some circumstances it may be
desirable to prevent access to a community beyond a predetermined time;
this is enabled by the exipirationDate feature. If set to
||An optional ID of the community's "parent" community. In some circumstances, it may be useful to create communities in a hierarchical manner, so this attribute allows tracking of this relationship.|
||A set of arbitrary properties associated with the community. The application may set and use these properties to store information about the community useful to the application framework.|
||A URI to the community registration page, which allows users to register for membership in the community. Users are automatically redirected to this page in certain circumstances by the portal framework. For more information see the discussion of registration pages.|
||A time zone associated with the community. The portal framework does not use this time zone in any manner, but it may be useful to applications written on the community framework to allow different communities to be localized to a specific time zone.|
||A localizable title for the community.|
CommunityDefinitionobject; this is just a list of the main attributes which apply to this overview of community functionality.
CommunityMemberobject stores the following information:
|external||boolean||This flag is not used internally by the communities framework, but is intended for possible use by community application implementations. The flag was conceived as a mechanism for storing whether the user was added to the system as a result of receiving an invitation or existed in the system previously. However, as this flag is not used internally be the communities or portal framework, applications may use it as they see fit.|
||A unique ID for the CommunityMember object, used to correlate it with
|wlsUserId||String||The WLS user id (login ID) of the user.|
CommunityMembershipobject stores the following information:
||A set of capabilities the user has within the community to which this membership object belongs. These capabilities can be defined and used by the application code to allow different levels of user access to a community. See the discussion of community capabilities for more information.|
||The community definition the membership belongs to.|
||A unique ID for the CommunityMembership object.|
||The date the membership was created.|
||The date this user last accessed this community; this is tracked
only if the CommunityDefinition's accessTrackingEnabled flag is
||The ID of the CommunityMember object representing the user for this CommunityMembership.|
CommunityContext.checkPermissions(javax.servlet.http.HttpServletResponse, boolean)method for the community in scope. This method may be useful for community application code in some circumstances as well.
publicflag to false,
true, and set up a registration page which automatically creates memberships for authenticated users. Thus, when a user without an existing membership attempts to access the community they will be automatically redirected to the registration page, which will automatically create a membership record for them, and the portal framework will automatically track their access to the community in the membership object. The registration page could even be set up to automatically redirect to the community after creating the membership- in this case, the user would not even need to know that they had been redirected to the registration page.
publicRegistrationEnabledflag could be set to
trueto allow users without memberships attempting to access the community to be redirected to the registration page so that they could apply for membership, even though they would need to be approved before the membership is actually created.
publicattribute is set to
true, the registration page cannot be part of the community desktop, as the portal framework will not allow users without memberships in the community to view any part of the community desktop. Multiple community instances may share a single registration page. Several utility classes exist which make implementing registration page functionality easier. For additional information, see the following objects:
CommunityContextis useful to get information about the community being registered for. It also contains methods to:
CommunityInvitationContextis useful for getting any invitations an authenticated user may have to join a community.
CommunityRedirectionHelperis useful in determining if the user arrived at the registration page due to an automatic redirect by the portal framework or by clicking on a link in an invitation. If multiple community instances are sharing a registration page, it has a method to determine which community instance the registration page is being invoked for. CommunityRedirectionHelper also has a utility method for generating a URL to a registration page for a community, which could be displayed in a community or elsewhere.
CommunityRedirectionHelperclass can help to determine which community instance the error page is being rendered for and why the error page is being rendered. If the community's
publicRegistrationEnabledattributes are set to
false, an unauthenticated user attempting to access the community will be automatically redriected to the error page, so it may be useful to offer login functionality on the error page. Error pages may be implemented using any technology; for example it could be a simple JSP, a single portlet or a portal. A descriptive and feature-rich sample error page implementation can be found in the community sample.
META-INF/communities-config.xmlfile. Example: In a discussion community, a
Moderatorcapabality could be defined such that only users with the
Moderatorcapabality in the community can approve or delete other members' submissions. Membership capabilities are represented in the community framework by the
MembershipCapabilityobject. This object also gives access to the complete set of membership capabilities configured for an enterprise application. Each
CommunityMembershipobject stores the set of all capabilities a membership has been granted. The
CapabilityRoleBootstrapperclass can be used at application deployment or configuration time to create default membership capability based role policies. These allow community applications to perform standard
isUserInRolecalls to determine if a user has a particular capability in the community in scope. They are set up as expression-based roles that use the current user's CommunityContext to determine capabilities, and cause the role evaluation to map to whether or not that user has the specified capability in the current community. When invitations are created, a set of membership capabilities can be added to the invitation so that when the user creates a membership from the invitation they automatically are given the capabilities.
CommunityDefinitionand must implement the
Communities may be created in a number of ways, both from the Portal Admin Tools or via programmatic means. Additionally, the Communities Framework supports mechanisms for assembling development time information necessary to create communities as well as means for creating templates from which actual Community Desktop instances can be created.
Programmatic creation of Communities is done via the
EJB persistence manager. Contained within this manager are methods to create Communities using only a reference
to a .portal file plus other required information in a CommunitiesInfo object, methods to create Communities based off
of other existing Community Desktops, methods to create Community Templates, and methods to create Communities based
off of an existing Community Template.
Community Templates are generally created, managed and accessed via the Portal Admin Tools, and may be part of either the Library or within individual Portals. Library Templates may be instantiated into Community Desktops anywhere within the enterprise application, while Templates within Portals are restricted to being instantiated within just that Portal.
Templates are useful for use cases where there is an archetypical type of Community that is expected to be created more than once, either by a Portal Admin or, via the Community Visitor Tools, by non-admin end users that are entitled to create Communities on their own. Communities created from a Template are identical to the Template Community Desktop except for desktop path (and portal path in the case of Library Templates), as well as anything else that is overriden on instantiation of the Community Desktop.
Using the Portal Admin tools, it is possible to create either a Community Template or a CommunityDesktop directly by specifying all of the required details for that type of resource. Since this typically involves a lot of information that may not originate with the Portal Administrator creating the Communities or Templates, developers have the option of creating .ctmeta files which can be used by the Portal Admin Tools to prepopulate the form fields on the Community Desktop and Template creation pages. This file type is ONLY used in the Portal Admin Tools, and is not something that can be read via the programmatic manager. Use of a .ctmeta file is not strictly required, but is highly recommended as manual input of all of the required information to create a Community Desktop or Template is complex and error prone.
Below is an example of a .ctmeta file. This is an XML file format that is based off of the netuix-communities-meta-1_0_0.xsd schema (netuix_schema.jar, /schema/netuix-communities-meta-1_0_0.xsd).
<communities-meta> <title>My Community</title> <description> <value>This is a Community.</value> </description> <community-dot-file>communities/myCommunity.portal</community-dot-file> <callback-class> <locked>true</locked> <value>com.bea.communities.MyCommunityCallback</value> </callback-class> <expiration> <value>2005-03-25T22:30:00</value> </expiration> <active> <value>true</value> </active> <public> <value>true</value> </public> <personal-pages> <locked>true</locked> <value>false</value> </personal-pages> <public-registration> <value>true</value> </public-registration> <registration-uri> <locked>true</locked> <value>communities/myCommunity/registration.jsp</value> </registration-uri> <error-uri> <locked>false</locked> <value>communities/myCommunity/error.jsp</value> </error-uri> <access-tracking> <locked>false</locked> <value>false</value> </access-tracking> <inviter-invoker-class> <locked>true</locked> <value>com.bea.communities.myCommunity.MyInviterInvoker</value> </inviter-invoker-class> </communities-meta>
|Copyright © 2000, 2008, Oracle and/or its affiliates. All rights reserved.|
|PREV PACKAGE NEXT PACKAGE||FRAMES NO FRAMES|