U.S. patent application number 11/752844 was filed with the patent office on 2007-09-13 for system and method for application flow integration in a portal framework.
This patent application is currently assigned to BEA SYSTEMS, INC.. Invention is credited to Sathyanarayana Giridhar, Philip B. Griffin, Jason Howes, Chris Jolley, Edward K. O'Neil, Jalpesh Patadia.
Application Number | 20070214421 11/752844 |
Document ID | / |
Family ID | 23525780 |
Filed Date | 2007-09-13 |
United States Patent
Application |
20070214421 |
Kind Code |
A1 |
Jolley; Chris ; et
al. |
September 13, 2007 |
SYSTEM AND METHOD FOR APPLICATION FLOW INTEGRATION IN A PORTAL
FRAMEWORK
Abstract
A system and a method for providing application flow integration
in a portal framework. In accordance with one embodiment, the
invention comprises a portal servlet, which handles all incoming
servlet requests and determines whether the incoming request
represents a request either for a portal page or for a non-portal
page; and, a portal processor which handles all portal page
requests passed by the portal servlet, and executes an appropriate
webflow to update the current state of the portal page, depending
on a current set of events. Each of a plurality of portlets may
have an individual webflow associated with it.
Inventors: |
Jolley; Chris; (Broomfield,
CO) ; Giridhar; Sathyanarayana; (Sammamish, WA)
; Griffin; Philip B.; (Longmont, CO) ; Howes;
Jason; (Somerville, MA) ; O'Neil; Edward K.;
(Boulder, CO) ; Patadia; Jalpesh; (Boulder,
CO) |
Correspondence
Address: |
FLIESLER MEYER LLP
650 CALIFORNIA STREET
14TH FLOOR
SAN FRANCISCO
CA
94108
US
|
Assignee: |
BEA SYSTEMS, INC.
2315 North First Street
San Jose
CA
95131
|
Family ID: |
23525780 |
Appl. No.: |
11/752844 |
Filed: |
May 23, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10279951 |
Oct 24, 2002 |
7240280 |
|
|
11752844 |
May 23, 2007 |
|
|
|
60386487 |
Oct 24, 2001 |
|
|
|
Current U.S.
Class: |
715/742 ;
707/E17.032 |
Current CPC
Class: |
G06F 2221/0766 20130101;
G06F 21/604 20130101; G06F 2221/0717 20130101; H04L 41/18 20130101;
G06F 21/6227 20130101; G06F 2221/2101 20130101; G06F 2221/2149
20130101; H04L 41/22 20130101; H04L 67/2842 20130101; H04L 69/22
20130101; H04L 67/06 20130101; H04L 69/329 20130101; H04L 67/2819
20130101; H04L 67/14 20130101; G06F 21/6218 20130101; H04L 67/34
20130101; H04L 67/16 20130101; G06F 16/275 20190101; H04L 67/36
20130101; H04L 63/102 20130101; Y10S 707/99933 20130101; Y10S
707/99953 20130101; Y10S 707/99931 20130101; H04L 67/306 20130101;
G06F 21/629 20130101; H04L 67/2838 20130101; H04L 29/06 20130101;
G06F 2221/0735 20130101; H04L 67/025 20130101; G06F 2221/0771
20130101; G06Q 10/10 20130101; G06F 2221/2145 20130101; G06F 16/986
20190101; G06F 2221/2141 20130101; G06F 16/954 20190101; H04L 67/02
20130101; H04L 67/2871 20130101; G06F 2221/2117 20130101; H04L
67/142 20130101; H04L 63/0884 20130101; G06F 2221/0706 20130101;
Y10S 707/99954 20130101; H04L 63/0815 20130101; G06F 16/958
20190101; G06F 16/80 20190101 |
Class at
Publication: |
715/742 |
International
Class: |
G06F 3/00 20060101
G06F003/00 |
Claims
1. A system for providing application flow integration in a portal
framework, comprising: a portal that provides access for users to
applications running at the portal; a portal state object which
represents a current state of the portal for a current user; a
portal servlet, which handles incoming requests and determines
whether the incoming request represents a request either for a
portal page or for a non-portal page; and a portal processorwhich
handles all portal page requests passed by the portal servlet, and
executes an appropriate webflow, including detecting the current
state of the portal, to update the flow of application logic within
the portal.
2. The system of claim 1 wherein the portal processor includes a
webflow executor for receiving the portal page requests.
3. The system of claim 1 wherein the portal processor invokes
webflow namespaces for the portal and any portlets to be rendered
for the request, and provides a URL to the portal servlet, which is
then used to forward the request to an appropriate servlet or Java
Server Page.
4. The system of claim 1 further comprising: a portal manager which
provides an interface between persisted portal data and a client of
that data, by assembling a portal state object for the current user
and returning it to the client.
5. The system of claim 1 wherein the system includes an individual
webflow for each of a plurality of portlets associated with the
portal.
6. A method for providing application flow integration in a portal
framework, comprising the steps of: providing a portal that
provides access for users to applications running at the portal;
representing the current state of the portal for a current user in
a portal state object; determining whether an incoming servlet
request represents a request either for a portal page or for a
non-portal page; and passing all portal page requests to a portal
processor, and executing an appropriate webflow, including
detecting the current state of the portal, to update the flow of
application logic within the portal.
7. The method of claim 6 wherein the portal processor includes a
webflow executor for receiving the portal page requests.
8. The method of claim 6 wherein the portal processor invokes
webflow namespaces for the portal and any portlets to be rendered
for the request, and provides a URL to the portal servlet, which is
then used to forward the request to an appropriate servlet or Java
Server Page.
9. The method of claim 6 further comprising: providing an interface
between persisted portal data and a client of that data, by
assembling a portal state object for the current user and returning
it to the client.
10. The method of claim 6 wherein the portal includes an individual
webflow for each of a plurality of portlets associated with the
portal.
11. A computer readable medium, including instructions stored
thereon which when executed cause the computer to perform the
steps: providing a portal that provides access for users to
applications running at the portal; representing the current state
of the portal for a current user in a portal state object;
determining whether an incoming servlet request represents a
request either for a portal page or for a non-portal page; and
passing all portal page requests to a portal processor, and
executing an appropriate webflow, including detecting the current
state of the portal, to update the flow of application logic within
the portal.
12. The computer readable medium of claim 11 wherein the portal
processor includes a webflow executor for receiving the portal page
requests.
13. The computer readable medium of claim 11 wherein the portal
processor invokes webflow namespaces for the portal and any
portlets to be rendered for the request, and provides a URL to the
portal servlet, which is then used to forward the request to an
appropriate servlet or Java Server Page.
14. The computer readable medium of claim 11 further including
instructions stored thereon which when executed cause the computer
to perform the additional steps comprising: providing an interface
between persisted portal data and a client of that data, by
assembling a portal state object for the current user and returning
it to the client.
15. The computer readable medium of claim 11 wherein the portal
includes an individual webflow for each of a plurality of portlets
associated with the portal.
Description
CLAIM OF PRIORITY
[0001] This application is a continuation of U.S. patent
application "SYSTEM AND METHOD FOR APPLICATION FLOW INTEGRATION IN
A PORTAL FRAMEWORK" application Ser. No. 10/279,951 filed on Oct.
24, 2002, which claims priority from provisional application
"ENHANCED PORTALS [FLAGSTAFF RELEASE]" Application No. 60/386,487,
filed Oct. 24, 2001, and incorporated herein by reference.
CROSS REFERENCE TO RELATED APPLICATIONS
[0002] This application is related to co-pending application
"SYSTEM FOR MANAGING LOGICAL PROCESS FLOW IN AN ONLINE ENVIRONMENT;
Inventors: Neil Smithline, and Sathyanarayana Giridhar, application
Ser. No. 09/908,023, filed Jul. 18, 2001, and subsequently issued
as U.S. Pat. No. 7,051,069 on May 23, 2006, which is incorporated
herein by reference.
COPYRIGHT NOTICE
[0003] A portion of the disclosure of this patent document contains
material which is subject to copyright protection. The copyright
owner has no objection to the facsimile reproduction by anyone of
the patent document or the patent disclosure, as it appears in the
Patent and Trademark Office patent file or records, but otherwise
reserves all copyright rights whatsoever.
Field of the Invention
[0004] The invention relates generally to portals, and particularly
to a system and a method for providing application flow integration
in a portal framework.
BACKGROUND
[0005] In the world of e-commerce, portal systems and applications
(more commonly referred to as "portals") are being increasingly
used to provide software applications and services to end-users and
third-parties. This is particularly important in the business
enterprise environment, or on the Internet (where portals are often
referred to as "Web portals"), since the portal can be used to
group together and manage a large number and a wide variety of
applications in a manner that allows those applications to be
effectively delivered to a large number of users, each of which may
have very different needs and access rights. The portal provides a
central access point and a common look-and-feel to the end user.
Portals can also be used to support collaboration between different
parties, so that for example, a third-party vendorapplication can
be integrated seamlesslywithin the enterprise platform.
[0006] Typically, the portal resides atop an application server,
such as the WebLogic server product from BEA Systems, Inc. A
product such as BEA WebLogic Portal, for example, delivers a
single, unified portal framework for all enterprise requirements by
providing foundation services that allow for sophisticated portal
development; personalization and interaction management,
intelligent portal administration to simplify and speed portal
deployment; and portal integration services that allow application
integration within and beyond the enterprise. Portlets, smaller
pre-built modular applications that are primarily based upon Java
Server Page (JSP) technology, execute within the portal, and can be
provided either as part of the portal or can be created by
third-parties. Portlets enable fast, out-of-the-box assembly and
deployment of an enterprise portal solution by providing common
application capabilities.
[0007] One of the problems with current portal offerings is they
lack a convenient mechanism to integrate the flow of a complex
software application ("application") within the framework of the
portal, so that the portal developer can easily include logic for
portal-related events. What is needed is a mechanism for allowing
the portal and the portlets, and other components therein, to
communicate with each other in a manner that supports application
flow within the portal as a whole.
SUMMARY
[0008] The invention relates generally to portals, and particularly
to a system and a method for providing application flow integration
in a portal framework. In accordance with one embodiment, the
invention comprises a portal servlet, which handles all incoming
servlet requests and determines whether the incoming request
represents a request either for a portal page or for a non-portal
page; and, a portal processor which handles all portal page
requests passed by the portal servlet, and executes an appropriate
webflow to update the current state of the portal page, depending
on a current set of events.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] FIG. 1 shows an architectural overview of a portal webflow
in accordance with an embodiment of the invention.
[0010] FIG. 2 shows a screenshot of a portal page that uses webflow
in accordance with an embodiment of the invention.
[0011] FIG. 3 shows a screenshot of a second portal page that uses
webfiow in accordance with an embodiment of the invention.
[0012] FIG. 4 shows an illustration of a portal webfiow in
accordance with an embodiment of the invention.
[0013] FIG. 5 shows a sequence diagram of a portal access in
accordance with an embodiment of the invention.
[0014] FIG. 6 shows a sequence diagram for changing the current
portal page (tab)in accordance with an embodiment of the
invention.
[0015] FIG. 7 shows a sequence diagram for re-rendering the portal
in accordance with an embodiment of the invention.
[0016] FIG. 8 shows sequence diagrams for various portlet window
events including minimize, maximize, un-maximize and edit, in
accordance with an embodiment of the invention.
[0017] FIG. 9 shows further sequence diagrams for various portlet
window events including minimize, maximize, un-maximize and edit,
in accordance with an embodiment of the invention.
[0018] FIG. 10 shows a sequence diagram of the links to self and
sibling in accordance with an embodiment of the invention.
[0019] FIG. 11 shows a sequence diagram of the self to sibling in
accordance with an embodiment of the invention.
[0020] FIG. 12 shows a class diagram of the portal appflow common
package in accordance with an embodiment of the invention.
[0021] FIG. 13 shows a class diagram of the portal servlet in
accordance with an embodiment of the invention.
[0022] FIG. 14 shows a sequence diagram of a servlet dispatcher in
accordance with an embodiment of the invention.
[0023] FIG. 15 shows a sequence diagram for helpers for a new
serviet request in accordance with an embodiment of the
invention.
[0024] FIG. 16 shows a sequence diagram for helpers for
manipulating HTTP servlet request attributes in accordance with an
embodiment of the invention.
[0025] FIG. 17 shows a sequence diagram for a portal processor
sequence in accordance with an embodiment of the invention.
DETAILED DESCRIPTION
[0026] Disclosed herein is a system and a method for providing
software application flow integration within a portal framework. In
particular, the disclosed invention allows a portal framework to be
supplemented with logical flow features such as webflow and
pipeline functionality. As used herein a "webflow" is a
state-machine-like mechanism that can be used to describe the flow
of application logic throughout the Web site or portal, including
the execution of business logic, error handling and dispatching.
The flow is based on both user events and programming events. This
state machine is then used as input to a webflow processor that
guides the system, and that combines Web links, form submissions,
form processing, business logic execution, and business logic
exceptions, into an easily managed schema. Any required change to
the logic flow of the system can be made by modifying just the
webflow itself.
[0027] Typically, the webflow guides the progress of the
interaction of the user with the actual e-commerce application. In
many cases, the e-commerce system or application may be a Web site
hosted on a Web server. Different types of application code can be
used to track and to modify the user interface. These may include
Java Servlet Pages (JSPs); input processing code which is used to
modify the user input; and pipeline processing code. When properly
configured, the webflow represents a tree structure along which the
user is guided. The tree structure includes presentation nodes and
actions nodes. Presentation nodes are what the customer actually
sees in their browser, for example, these may include HTML and JSP
files. While viewing the output from a presentation node, the
customer's data is stored in a pipeline session. A pipeline session
is a set of attributes which may in one embodiment be name value
pairs which hold pertinent data on a given customer during a given
session. Since the webflow acts like a state like machine, the
pipeline session defines a current state for a given customer. The
data stored in the pipeline session are used throughout the webflow
to provide information to other features and services.
[0028] Action nodes perform the actual work for the e-business
site, and include such features as input processors and pipelines.
Input processors handle the attributes of the pipeline session.
Typically the input processor may either: (a) put the attribute in
the pipeline session; (b) modify the value of existing attributes
within that pipeline session; or (c) validate values of particular
attributes within the pipeline session. A pipeline controls the
flow of the business logic within the e-commerce site. Typically
the pipeline comprises many pipeline components. A pipeline
component is an object responsible for doing a particular portion
of the business logic. Each pipeline component is thus a unit of
business functionality. The developer may combine the use of a
webflow together with input processors and pipeline to modify their
business functionality with ease of use and in real time. Further
details about the use of webflow and pipelines in an e-commerce
environment is presented in co-pending application "SYSTEM FOR
MANAGING LOGICAL PROCESS FLOW IN AN ONLINE ENVIRONMENT; Inventors:
Neil Smithline, and Sathyanarayana Giridhar, incorporated herein by
reference.
[0029] The present invention provides a mechanism for providing
software application flow integration, including such features as
the webflow and pipelines described above, within a portal
framework. In particular, the disclosed invention provides patterns
for using webflow and pipeline technologies within a portal or with
portlets. This allows the invention to provide a declarative means
for developing portals and portlets. In addition a framework is
provided for handling portal page events and portlet window events.
A declarative means is provided for portal developers to add
additional logic for framework supported events. A declarative
means is also provided for handling any portal or portlet events.
Lastly, a means is provided for communicating between the portlets
and/or the portal and portlets.
[0030] The use of Webflow is not mandatory in developing the
portal--instead it may be considered an advanced feature of the
Portal development platform. Whether webflow is used in a
particular portal depends on the particular needs and design of the
application. Some reasons to use Webflow in individual portlets
include:
[0031] To separate business logic from presentation;
[0032] To coordinate the navigation of a Web site with the
execution of business logic;
[0033] To reuse existing InputProcessors and PipelineComponents;
and,
[0034] To link business logic execution across portlets.
[0035] Throughout the following description of a particular
embodiment, it is assumed that only one portal may be deployed per
web application; and that a portal web application may include
conventional web pages (non-portal pages), along with the portal
(portal page, maximized portlet page). However, it will be evident
to one of skill in the art that in alternate embodiments of the
invention different assumptions may be made.
Portal Web Application
[0036] A portal web application is usually comprised of a portal
jsp page and, optionally, one or more conventional web pages. The
invention assists in declaring access to, and transition between,
the portal jsp page and conventional web pages, including for
example in the following cases:
[0037] Initial access to the portal from outside the web
application,
[0038] Changing the portal page (tab),
[0039] Refreshing the portal,
[0040] Portlet window events,
[0041] Generic portal links, and,
[0042] Generic portlet links.
Component Level Architecture
[0043] Functionally, five primary components make up the design:
Portal Servlet, Portal Processor, PortalState object, PortalSession
object and the Portal Manager.
[0044] The Portal Servlet handles all incoming servlet requests and
determines whether they represent a request for either a portal
page or a non-portal page. Non-portal page requests utilize the
standard webflow (as described in further detail in copending
application "SYSTEM FOR MANAGING LOGICAL PROCESS FLOW IN AN ONLINE
ENVIRONMENT"; Inventors: Neil Smithline, and Sathyanarayana
Giridhar), and are routed to the standard webflow executor
unmodified. Portal page requests are however directed through the
webflow executor to the Portal Processor for subsequent
handling.
[0045] The Portal Processor handles all portal page requests. For
each request, the Portal Processor obtains the current PortalState
object for the request, and then executes appropriate framework
logic to adjust the current state depending on the current appflow
event. The Portal Processor then invokes webflow namespaces for the
portal and all portlets to be rendered for the request. The webflow
namespaces should declaratively cause execution of appropriate
business logic for the given request. When the Portal Processor
returns, it provides a URL to the Portal Servlet which is used to
forward the request to the appropriate servlet (or jsp).
[0046] The PortalState object represents the current state of the
Portal for the current user. The object returned by the Portal
Manager contains only the persistent state for the current user.
The Portal Processor augments this persistent state with the state
of the current session (PortalSession). From the view of the
rendering engine, realized in portal.jsp, the PortalState object
contains all state for the current user, i.e. both the persistent
and the session-based state. PortalState objects are intended to be
used only for a single request.
[0047] The PortalSession is used to maintain the current portal
page (tab) for the user and the content jsp page for each
portlet.
[0048] The Portal Manager provides an interface between persisted
portal data (XML and database data) and the clients of that data.
The Portal Manager, with the aid of the entitlement engine,
assembles a PortalState object for the current user and returns it
to the client.
Webflow and the Portal Platform
[0049] To customize the behavior of the portal Web application,
whether this means creating special navigation logic for a simple
portlet, or developing complex business and presentation framework
customizations that change the portal platform, to suit a
particular business case, a basic understanding of Webfiow is
required. FIG. 1 shows the architecture of the portal framework or
platform 100 in accordance with an embodiment of the invention, and
illustrates howWebflowfunctionality can be implemented within the
portal application. Because its main function is to serve as a
structure of reusable presentation and navigation modules, the
Portal framework itself can be thought of primarily as one large
Webflow application. For the most part, Webflow functionality is
invoked in a similar way within the Portal framework as it is
within the WebLogic Server platform (as described in further detail
in copending application "SYSTEM FOR MANAGING LOGICAL PROCESS FLOW
IN AN ONLINE ENVIRONMENT"), with the primary difference being that
the Webflow servlet performs most of the routing between
validation, session logic and custom processor nodes. As shown in
FIG. 1, the webflow servlet 102 passes all portal page requests via
the portal webflow servlet 104 to the webflow executor 106, for
subsequent handling by the portal processor 107. For each request,
the portal processor obtains the current portal state object for
the request, and then executes appropriate framework logic 112,
114, 116, 118, 120, and knowledge of the current session 108, 110,
to adjust the current state depending on any current application
flow event. The portal processor returns a URL to the portal
servlet which is then used to forward the request to the
appropriate servlet or jsp.
[0050] Webflow and Portal can be thought of as two complementary
navigation mechanisms. The portal platform provides an array of
content placeholders, each able to function as a virtual browser
that controls its own state without influencing the state of its
neighbor portlets. The Webflow mechanism is designed to enable the
navigation logic of a web application to be controlled by a
multitude of factors, so that Personalization, etc., can all be
coordinated to influence what is presented to the Web site visitor
at runtime. Each individual portlet can be assigned its own
particular Webflow. The following section explains the basic
requirements in using Webflows with portlets.
Portlets and Webflow
[0051] The Webflow associated with portals are generally not edited
by the application developer because it is fundamental to the
application logic that makes up the portal platform. Individual
portlets, however, can have individual webflows (in the form of
Webflow files) assigned to them, allowing Webflow functionality to
be applied to each portlet.
Portlet Webflow Parameters
[0052] Portal Webflow is invoked with the following three
parameters:
[0053] Portlet Webflow Namespace: Portlet namespace handling allows
the Webflow Servlet to discern individual portlets when handling
events within a portal.
[0054] Event: Portlet Webflows listen for as many as seven events
related to user actions within a portlet.
[0055] Origin: Unlike a typical web application using Webflow, the
Portal server must keep track of the current node for each portlet
Webflow being displayed. This current node information may be
considered for each new event.
[0056] In one embodiment, the portal framework uses the following
portlet events, all of which must be handled when Webflow is
invoked:
[0057] Refresh--Required of all Webflows,
[0058] Maximize--Required if Maximizable and no Maximize URL
specified in portlet definition,
[0059] unMaximize--Required if Maximizable and no Maximize URL
specified in portlet definition,
[0060] Edit--Required if Editable and if no Edit URL specified in
portlet definition,
[0061] unEdit--Required if Editable and if no Edit URL specified in
portlet definition,
[0062] Minimize--Required if portlet is minimizable (No Minimize
URL needed),
[0063] unMinimize--Required if portlet is minimizable (No Minimize
URL needed).
[0064] These events are called when the corresponding actions are
performed, and are handled by the portal framework. These events
can be used within custom portlets, and a developer can also define
their own events. Custom events can be added if desired, and can be
triggered from within custom portlets, or alternatively they can be
triggered by portlet framework events.
The Refresh Event
[0065] Understanding Webflow in portals requires a grasp of the
Refresh event. To illustrate the way this event is used, consider
the page view 130 of the sample portal screenshot shown in FIG. 2.
If a site visitor minimized portlet2, a refresh event would be sent
to both the other portlets 131, 133 via the PortalWebflowServlet
104, illustrated in FIG. 1. It is this refresh event which allows
one portlet to communicate with or respond to another portlet.
The Origin Parameter
[0066] Portlet Webflows do not use Origin differently than other
web applications. Consider what happens when a user clicks on the
"Next Page" link 136 in Portlet2 as shown in FIG. 2. The Webflow
fragment shown below indicates that the presentation node defined
as the origin is "portlet," and the destination node declared for
that origin is portletB. TABLE-US-00001 <presentation-origin
node-name="portlet" node-type="jsp"> <node-processor-info
page-relative-path="/portlets/portlet2'' page-name"port]
<event-list> <!-- next --> <event
event-name="switch"> <destination namespace="portlet2''
node-name="portletB" node-type="jsp"/> </event>
</event-list> </presentation-origin>
[0067] Clicking on the "Next Page" link in page 1 of Portlet2 takes
the visitor to Page 2 (138), as shown in FIG. 3. To understand how
the "Previous Page" link 140 on Page2 is made to point to the
initial presentation node designated for Portlet2, consider the
Webflow fragment shown below: TABLE-US-00002
<presentation-origin node-name="portletB" node-type="jsp">
<node-processor-info page-relative-path="/portlets/portlet2''
page-name"port <event-list> <!-- back --> <event
event-name="switch"> <destination namespace="portlet2''
node-name="portlet" node-type="jsp"/> </event>
</event-list> </presentation-origin>
[0068] Considering this simple example illustrating the Origin
parameter and the way Refresh events are handled in the portal
framework, it is apparent that much customization can be
accomplished without writing any Java code.
[0069] FIG. 4 is an image from the Webflow editor, which can be
used to edit webflows for each portlet, showing an example of a
portlet Webflow which navigates from one JSP 142 to another 144 and
back.
[0070] A few general reminders should be followed when using
webflows within portlets:
[0071] When using Webflow within a portlet, the developer must use
a portlet-specific JSP tag. Where a non-portal web application
would invoke Webflow using <wf:CreateWebflowURL/>tag, you
would use the following tag within a portlet:
<portlet:CreateWebflowURL/>.
[0072] To refer to the saved state of a portlet, LastContentURL can
be used to denote a special destination informs the portal engine
to display the last/current JSP. For example: <destination
namespace="portal" node-name="lastContentUrl"
node-type="portal"/>
[0073] Another special destination, "portalRefreshProcessor" is
used to refresh the portal or return from a "regular" webflow back
to the portal. For example: <destination namespace="portal"
node-name="portalRefreshProcessor"
node-type="inputprocessor"/>
[0074] For all refresh events, a wildcard event handler can be used
with last LastContentURL. This enables back-end processing without
changing the front-end state of the object.
Lifecycle for Initial Portal Access
[0075] FIG. 5 shows a sequence diagram 150 of a portal access in
accordance with an embodiment of the invention, and illustrates
accessing the portal from either inside or outside the current web
application. As shown in FIG. 5, the user (or "visitor") accesses
the portal web application (and the portlet) with an appropriate
url. Since no namespace is associated with the request, the
internal helper method returns false. The webflow executor examines
the request and determines that no namespace is specified and no
user session exists, so the default namespace is used. Likewise, no
event is specified so the executor uses the begin event.
Consequently the executor invokes the Portal Processor.
[0076] In the general case, access should be through a generic url
such as: http://www.company.com/myPortal (with no additional query
string or extra path information), and the portal for an anonymous
visitor at the default portal page (tab) should be displayed.
[0077] Example URL TABLE-US-00003
<host>:<port>/<portal web app>/
<host>:<port>/<portal web
app>/namespace=<portal namespace>
[0078] Variations on the above include the ability to authenticate
the visitor via a cookie, or by some other means, and render the
default portal page (tab) for this visitor.
Changing the Portal Page
[0079] FIG. 6 shows a sequence diagram 160 for changing the current
portal page (tab). The Portal Processor is called via declarative
logic.
[0080] Example URL TABLE-US-00004
<host>:<port>/<portal web
app>/namespace=<portal
namespace>&origin=portal.jsp&event=portal.page.<page
name>
Portal Refresh
[0081] FIG. 7 shows a sequence diagram 170 for re-rendering the
portal.
[0082] Example URL TABLE-US-00005
<host>:<port>/<portal web
app>/namespace=<portal namespace>&origin=<some
origin>&event=portal.refresh
Portlet Window Events
[0083] FIG. 8 and FIG. 9 show sequence diagrams (180 and 190
respectively) for various portlet window events including minimize,
maximize, un-maximize and edit.
[0084] Example URL TABLE-US-00006
<host>:<port>/<portal web app>/namespace=<some
portlet namespace>&origin=<some
origin>&event=portal.portlet.<event>
where <event> is one of minimize, maximize, unmaximize or
edit. Generic Portal Links
[0085] The application flow use cases described in further detail
below illustrate several types of links that may be made available
to a portal developer for use within portal areas of the portal
page. These include "self"; "sibling"; "in"; and "out". The
following are example uris that correspond to these link types:
TABLE-US-00007 Self: <host>:<port>/<portal web
app>/namespace=<portal namespace>&origin= <some
origin>&event=<some non-portal event> Sibling:
<host>:<port>/<portal web
app>/namespace=<portal namespace>&origin=<some
origin>&event=<some non-portal event>
(Sibling is the same as self but refreshing the portlets changes 1
or more portlet content pages) [0086] In: namespace=<non-portal
namespace>&origin=<some origin>&event=<some
event> (relative URL) [0087] Out:
<host>:<port>/<some web app>/
[0088] FIG. 10 shows a sequence diagram 200 of the links to self
and sibling.
Generic Portlet Links
[0089] The application flow use cases described in further detail
below illustrate several types of links that may be made available
to a portal developer for use within portlet areas of the portal
page. These also include "self"; "sibling"; "in"; and "out". The
following are example uris that correspond to these link types:
TABLE-US-00008 Self: <host>:<port>/<portal web
app>/namespace=<some portlet
namespace>&origin=<some origin>&event=<some
non-portal event> Sibling: <host>:<port>/<portal
web app>/namespace=< some portlet
namespace>&origin=<some origin>&event=<some
non-portal event>
(Sibling is the same as self but the portlet changes its content
page) [0090] In: namespace=<non-portal
namespace>&origin=<some origin>&event=<some
event> (relative URL) [0091] Out:
<host>:<port>/<some web app>/
[0092] FIG. 11 shows a sequence diagram 210 of the self to
sibling.
Object Implementations
[0093] The following section describes some object implementations
in accordance with a particular embodiment of the invention as it
may be used with a product such as WebLogic Server from BEA
systems, Inc. to provide application flow in a portal framework.
The following object descriptions are not intended to be exhaustive
but merely to illustrate a particular embodiment. It is intended
that alternate implementations may be developed by those skilled in
the art, within the spirit and scope of the invention.
Com.bea.portal.appflow.common Package
[0094] FIG. 12 shows a class diagram 220 of the portal appflow
common package.
Com.bea.portal.appflow.servlet Package
[0095] FIG. 13 shows a class diagram 230 of the portal servlet.
[0096] FIG. 14 shows a sequence diagram 240 of a servlet
dispatcher.
Com.bea.portal.appflow.internal Package
[0097] FIG. 15 shows a sequence diagram 250 for helpers for a new
serviet request.
[0098] FIG. 16 shows a sequence diagram 260 for helpers for
manipulating HTTP serviet request attributes.
[0099] FIG. 17 shows a sequence diagram 270 for a portal processor
sequence.
[0100] The foregoing description of the present invention has been
provided for the purposes of illustration and description. It is
not intended to be exhaustive or to limit the invention to the
precise forms disclosed. Many modifications and variations will be
apparent to the practitioner skilled in the art. The embodiments
were chosen and described in order to best explain the principles
of the invention and its practical application, thereby enabling
others skilled in the art to understand the invention for various
embodiments and with various modifications that are suited to the
particular use contemplated. It is intended that the scope of the
invention be defined by the following claims and their
equivalence.
* * * * *
References