Welcome to portal development. This section of the help system provides overview information, reference topics, and procedures that guide you through the portal development process using the WebLogic Workshop Portal Extensions.
The WebLogic Workshop Portal Extensions provide more than a powerful, flexible, extensible framework for surfacing applications in portals. They also provide personalization, campaign, and behavior tracking services, a rules engine, JSP tags, integration services, intelligent administration, reusable samples, and a complete API.
Choose from the following subsections to learn more about WebLogic Portal, explore the power of the product with tutorials and samples, start developing or integrating your own portal applications, or access reference information.
Overview
Introduces portals and the WebLogic Portal architecture and provides guidance on getting started with WebLogic Portal.
Developing Portal Applications
Provides instructions on adding portal functionality to existing applications, developing new portal applications, and building portlets. This section includes information on integrating Web applications, struts applications, and Web services; building Web, JSP, Java Page Flow, and commerce applications; and creating portlets.
Developing Personalized Applications
Provides instructions for adding personalization and campaigns to your portal applications.
Developing Portal User Interfaces
Describes the WebLogic Portal user interface framework and provides instructions for creating a portal user interface and developing user interface resources. This section also provides guidance on building user interfaces to address accessibility guidelines.
Assembling Portal Applications
Provides instructions for assembling portals with existing portal resources, such as creating a portal file, adding books and pages to desktops, changing page layouts, changing the look & feel, and changing the shell.
Securing Portal Applications
Describes the security touch points in a portal development scenario and provides links to instructions that relate to those touch points. This section also describes how WebLogic Portal implements the WebLogic Server security service provider interface (SSPI).
Deploying Portal Applications (edocs)
Provides detailed information and best practices for deploying portal applications.
Portal Reference
Includes Javadoc for WebLogic Portal and partner APIs, a WebLogic Portal JSP tag reference, WebLogic Portal samples, and other reference information.
What is a Portal?
A portal represents a Web site that provides a single point of access to applications and information and may be one of many hosted within a single WebLogic Portal server.
Portals are becoming more and more important to companies, who have an ever-increasing need to provide employees, partners, and customers with an integrated view of applications, information, and business processes. WebLogic Portal meets these needs, allowing companies to build portals that combine functionality and resources into a single interface while enforcing business policies, processes, and security requirements, and providing personalized views of information to end users.
From an end user perspective, a portal is a Web site with pages that are organized by tabs or some other form of navigation. Each page contains a nesting of sub-pages, or one or more portlets—individual windows that display anything from static HTML content to complex Web services. A page can contain multiple portlets, giving users access to different information and tools in a single place. Users can also customize their view of a portal by adding their own pages, adding the portlets they want to it, and changing the look and feel of the interface.
The business problem that portals solve is illustrated in the following example. A company has the need for several types of Web presence: an Intranet for its employees, a secure site for interactions with partners, and a public Web site. WebLogic Portal’s flexible portal network architecture supports multiple implementation choices which allow re-use of resources across portals.
Portals in Java 2 Enterprise Edition (J2EE) Terms
From a J2EE standpoint, WebLogic Portal is an enterprise application consisting of Enterprise Java Bean (EJB) components and a set of Web applications. The enterprise application contains the core application programming interfaces (API), and the Web applications contain servlets, Java Server Pages (JSPs), JSP tag libraries, and supporting Java classes.
The WebLogic Portal architecture allows multiple portals per Portal Web application, letting you flexibly build and leverage Web application resources and security in multiple portal deployments.
Technically speaking, a portal is a container of resources and functionality that can be made available to end-users. These portal views, which are called Desktops in WebLogic Portal, provide the uniform resource location (URL) that users access.
Components that Make up a Portal
In WebLogic Portal, a portal definition is a single XML file. The XML file is created automatically as you build a portal with the Portal Designer that is provided as part of the WebLogic Workshop Portal Extensions. The portal file contains all the components that make up that particular instance of the portal, such as books, pages, portlets, and look and feel components.
Many components have a hierarchical relationship to each other. For example, a book contains pages and pages contain portlets. The Document Structure illustration shows the relationship between components in a portal file. Following are descriptions of the components that make up a portal interface.
Desktop - A desktop is is an audience specific view of portal components. It contains the portal header, footer, and body. The body contains the bulk of the portal content: books, pages, portlets, and look and feel elements. A portal can support one or more desktops. After a portal administrator sets entitlements on the desktop and makes it ready for public consumption, the desktop is the view of the portal accessed by end users. From there, users may configure their own views through customization of the desktop. Think of a desktop as a user view of a Web site or a portal, exposing a different set of information or tools based on user context. For example, each department in an organization (Human Resources, Accounting, Legal, Sales) can define a portal desktop containing its own portlets, navigation, and look and feel, yet these desktops are all supported by a single portal definition.
Shell - A desktop's header and footer, controlled by a portal shell (.shell file), are the areas that are typically above and below the main body. These areas usually display such things as personalized content, banner graphics, legal notices, and related links.
Book - A Book is a component that provides high-level content organization and navigation. Books contains pages or other books, providing a mechanism for hierarchical nesting of pages and content. Books are identified by a control such as a tab set.
Page - Pages contain the portlets that display the actual portal content. Pages can also contain books and other pages. Pages are identified by a control such as a tab set.
Layout and Placeholder - A layout is an HTML table definition used by a page to determine the physical locations of portlets on the page. Administrators and users can choose different available layouts for pages. Placeholders are the individual cells in a layout in which portlets are placed.
Portlet - Portlets are the windows that surface your applications, information, and business processes. They can contain anything from static HTML content to Java Controls to complex Web services and process-heavy applications. Portlets can communicate with each other and take part in Java Page Flows that use events to determine a user's path through an application. You can have multiple portlets on a page. You can also have multiple instances of a single Portlet. For example, you can put instances of a portlet on multiple pages; so that if users don't have rights to view one page with that portlet on it, they can see the portlet on a page they do have rights to view. Portlets can have different modes, such as minimize, maximize, edit, delete, configure, and help, selectable from their title bars.
Portal Rendering and Look and Feel Components (not shown in the illustration) - A desktop's appearance is determined by the Look and Feel. A look and feel definition contains two major elements: skins and skeletons.
Skins - Skins provide the overall colors, graphics, and styles used by all components in a desktop interface. Skins are collections of graphics and cascading style sheets (CSS) that allow changes to be made to the look and feel of a portal without modifying the portal components directly. References to images and styles are made in the skin rather than being hard coded into the portal definition. The look and feel file provides a path to the skin directory to be used. Themes are subsets of skins that you can apply to books, pages, and portlets, providing a way of using a different set of styles for individual desktop components.
Skeletons - The look and feel file also provides a path to the skeleton directory to be used. Every type of component, from a desktop to a portlet's title bar, has an associated JSP file, called a skeleton file, that renders it. Some skeleton files are simple, others are more complex. For example, each desktop uses a skeleton file called shell.jsp that simply provides the opening and closing tags to render the desktop. A portlet title bar, on the other hand, has a skeleton file called titlebar.jsp that is more complex. It contains Java calls to various windowing methods in the API, references the button graphics to use on the title bar, and determines the placement of title bar elements with an HTML table definition.
After the logic in the skeleton servlets executes for a look and feel, components are rendered hierarchically into a single HTML instance that is the user view of the desktop.
Administrators and users can select from a list of available look and feel definitions, which changes the appearance, and sometimes the behavior, of a user's view of a desktop. For example, the header of one look and feel can contain a static graphic, while the header of another look and feel can contain a campaign that targets a user with personalized content from a content repository.
Portal Development Tools and Services
WebLogic Portal includes many powerful tools and services that make portal development fast and easy.
Designers and Samples - The WebLogic Workshop Portal Extensions include a Portal Designer and a Portlet Designer that provide graphical drag and drop functionality and grid-based property setting, letting you create a sophisticated portal in minutes. For example, you can create a portal file (that appears with a default page), drag one of the sample JSPs from the file tree onto the default page, and a portlet is created for you automatically. You can then save the file and view the portal desktop in a browser.
Java Controls - WebLogic Workshop Enterprise Edition includes many powerful Java Controls that insulate developers from lower-level coding, reducing the lines of code they must write (and therefore reducing the number of bugs). WebLogic Portal provides several Java Controls to assist development of personalized applications, such as a User Profile Control and a Display Content Control.
Portal Java Controls increase developer productivity for application development. Instead of writing code to access an API or J2EE resource directly or even using JSP tags, a developer can insert the User Profile Control into a JSP or Java Page Flow and select the appropriate methods for retrieving and updating user profile information, determining whether or not a user exists, or retrieving a list of users based on search parameters.
JSP Tags - The WebLogic Workshop Portal Extensions include a library of JSP tags that let you perform useful tasks in JSPs with minimal coding.
Content Management - WebLogic Portal includes powerful content management functionality, letting you integrate and manage multiple content management systems in a single virtual content repository. As a developer you can query the repository and retrieve and display personalized content in your portal applications. The Virtual Content Repository is set up and managed in the WebLogic Administration Portal and supports the full development lifecycle.
Unified User Profile - WebLogic Portal includes a unified user profile service that lets you add, access, and manage users and their properties in a single logical location—even if the base set of user data is stored on an external system such as an LDAP server. The unified user profile is a key element in such things as triggering personalization, setting role-based administration, and creating end user entitlements to portal resources.
Personalization, Interaction Management, and Behavior Tracking - The Portal Resources Designer lets you define the properties, rules, and actions that display personalized Web content to users, send automatic e-mails, or provide automatic discounts. The designer lets you create campaigns, content selectors, placeholders, and user profile and other properties. The WebLogic Workshop Portal Extensions also provide a set of events for tracking user behavior in portals, and the designer lets you register any custom events you develop.
APIs - WebLogic Portal includes an extensive set of APIs you can use directly for custom application development. For example, the Expressions Package provides a set of expressions that let you construct complex content queries.
Creating a Portal
Creating a portal involves using the WebLogic Portal framework and tools to surface applications in a portal user interface. It also involves adding personalization, campaigns, and behavior tracking to your applications.
You can quickly and easily integrate your own applications into WebLogic Workshop and apply WebLogic Portal's framework, tools, and services to them, or you can create new portal applications in WebLogic Workshop.
The following sections guide you through the process of creating a portal:
Developing Portal Applications
Provides instructions on adding portal functionality to existing applications, developing new portal applications, and building portlets. This section includes information on integrating Web applications, struts applications, and Web services; building Web, JSP, Java Page Flow, and commerce applications; and creating portlets.
Developing Personalized Applications
Provides instructions for adding personalization and campaigns to your portal applications.
Developing Portal User Interfaces
Describes the WebLogic Portal user interface framework and provides instructions for creating a portal user interface and developing user interface resources. This section also provides guidance on building user interfaces to address accessibility guidelines.
Assembling Portal Applications
Provides instructions for assembling portals with existing portal resources, such as creating a portal file, adding books and pages to desktops, changing page layouts, changing the look & feel, and changing the shell.
Creating a Portal Application and Portal Web Project
To create the necessary resources for portal development, you must do one of two things:
- Option 1: Create a new portal application and add a Portal Web Project to it
or - Option 2: Install Portal into an existing application and add a Portal Web Project to it
Following are the procedures for each option.
Option 1: To create new portal application and add a Portal Web project to it
Use this procedure to create a new portal application.
You do not need to perform these steps if you are developing on a shared domain and the portal application has already been created and stored in a version-control system. Simply synchronize to the current version of the domain to put the portal application on your machine.
1. If you have not yet created a portal domain on your development machine, create one with the Configuration Wizard. For instructions, see the Overview of Platform Configuration on the BEA's e-docs Web site.
Performing this step ensures you have a server (config.xml) for your portal application to use, as described later in this procedure.
Performing this step ensures you have a server (config.xml) for your portal application to use, as described later in this procedure.
2. Create a new portal application. In WebLogic Workshop Platform Edition, choose File -->New -->Application.
3. In the New Application window, select Portal Application in the right pane.
4. In the Directory field, click Browse to set the location of the new application. The application will be created in a subdirectory of the directory you select.
5. Make sure the Name field contains the name of the application. This name will be the application directory.
6. In the Server field, click Browse and select the config.xml file for the server (domain) you want to use.
The config.xml file is in the portal domain directory you created.
The config.xml file is in the portal domain directory you created.
7. Click Create. The application directory appears in the Application window. The application contains the WebLogic Administration Portal (contained in Modules/adminPortal.war), a datasync directory (data) for interaction management development, and application-level EJBs and APIs.
8. Create a portal Web project for your application. Right-click the directory in the Application window, and choose New -->Project.
9. In the New Project window, select Portal Web Project in the right pane.
10. In the Project name field, enter the name for the portal Web project. This will be the name of a Web application directory.
11. Click Create. The project folder appears in the Application window. The portal Web project contains WebLogic Portal JSP tags, Web-application-level APIs, and default portal framework files.
12. If you have any external projects or files you want to include in your portal application, perform any of the following steps:
o To import a project, right-click the directory in the Application window and choose Import Project. In the Import Project window, select the type of project to import, browse to select the project folder, and click Import.
o To import files, such as existing datasync files (User Segments, Campaigns, Placeholders, and so on) or the Workshop Portal Extensions sample portlets to use in your portals , right-click the appropriate directory in the Application window and choose Import. In the Import Files window, select the directory or files you want to import, and click Import.
The sample portlets are located in \\samples\portal\portalApp\sampleportal\portlets. There are other useful sample files throughout the \\samples directory. See the instructions in Portal Samples for more information.
The sample portlets are located in \\samples\portal\portalApp\sampleportal\portlets. There are other useful sample files throughout the \\samples directory. See the instructions in Portal Samples for more information.
You now have the resources and directories for developing personalized applications and creating portals to surface applications.
13. Start your development server. In WebLogic Workshop, choose Tools-->WebLogic Server-->Start WebLogic Server. The server you assigned to your application in the previous steps starts. All your work is deployed automatically on your machine as you develop.
Option 2: To install portal in an existing application and add a Portal Web project to it
Use this procedure to add portal services to an existing application.
You do not need to perform these steps if you are developing on a shared domain and the portal-enabled application has already been created and stored in a version-control system. Simply synchronize to the current version of the domain to put the portal application on your machine.
1. In WebLogic Workshop Platform Edition, open the application in which you want to install portal.
2. In the Application window, right-click the directory and choose Install-->Portal. WebLogic Workshop adds the WebLogic Administration Portal (contained in Modules/adminPortal.war), a datasync directory (data) for interaction management development, and application-level EJBs and APIs.
3. Create a portal Web project for your application. Right-click the directory in the Application window, and choose New-->Project.
4. In the New Project window, select Portal Web Project in the right pane.
5. In the Project name field, enter the name for the portal Web project. This will be the name of a Web application directory.
6. Click Create. The project folder appears in the Application window. The portal Web project contains WebLogic Portal JSP tags, Web-application-level APIs, and default portal framework files.
7. If you have any external projects or files you want to include in your application, perform any of the following steps:
o To import a project, right-click the directory in the Application window and choose Import Project. In the Import Project window, select the type of project to import, browse to select the project folder, and click Import.
o To import files, such as existing datasync files (User Segments, Campaigns, Placeholders, and so on) or the Workshop Portal Extensions sample portlets to use in your portals , right-click the appropriate directory in the Application window and choose Import. In the Import Files window, select the directory or files you want to import, and click Import.
The sample portlets are located in \\samples\portal\portalApp\sampleportal\portlets. There are other useful sample files throughout the \\samples directory. See the instructions in Portal Samples for more information.
The sample portlets are located in \\samples\portal\portalApp\sampleportal\portlets. There are other useful sample files throughout the \\samples directory. See the instructions in Portal Samples for more information.
You now have the resources and directories for developing personalized applications and creating portals to surface applications.
8. Start your development server if it is not already running. In WebLogic Workshop, choose Tools-->WebLogic Server-->Start WebLogic Server. All your work is deployed automatically on your machine as you develop.
Comments
Post a Comment