(12) United States Patent
`US 7,814,423 B2
`(10) Patent N0.:
`Musson et a1.
`Oct. 12, 2010
`(45) Date of Patent:
`
`USOO7814423B2
`
`(54)
`
`(75)
`
`IVIETHOD FOR PROVIDING A GRAPHICAL
`USER INTERFACE
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`Inventors: Scott Musson, Arvada, CO (US);
`Christopher Jolley, Broomfield, CO
`(US); George Murnock, Longmont, CO
`(US); Subrahmanyam Allamaraju,
`Longmont, CO (US); Brodi Beartusk,
`Lafayette, CO (US); Robert Bergman,
`Denver, CO (US): James D’Ambrosia,
`Westminster, CO (US); Kevin Blair
`Frender, Longmont, CO (US); Stephen
`Hetzel, Boulder, CO (US);
`Purushotham Babu Naidu, Lafayette,
`CO (US); Sameer Sawant, Bouldcr, CO
`(US)
`
`5,295,243
`6,115,040
`6,223,145
`6,249,291
`6,268,852
`6,327,628
`6,486,895
`6,671,853
`6,778,193
`6,961,750
`7,028,261
`
`........... 715/848
`
`3/1994 Robertson et a1.
`A *
`9/2000 Bladow et 211.
`A
`4/2001 Hearst
`......................... 703/22
`B1 *
`6/2001 Popp et al.
`B1
`
`7/2001 Lindhorst et a1.
`B1 *
`..
`.. 715/744
`B1“ 12/2001 Anuffet a1.
`................. 719/311
`B1
`11/2002 Robertson et a1.
`B1
`12/2003 Burkett et a1.
`B2 *
`8/2004 Biebesheirner et a1.
`B1
`11/2005 Burd et a1.
`
`...... 7 1 5/805
`
`B2 *
`
`4/2006 Smyth et a1.
`
`................ 715/744
`
`(73)
`
`Assignee: BEA Systems, Inc., Redwood Shores,
`CA (US)
`
`(Continued)
`OTHER PUBLICATIONS
`
`(*)
`
`Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 790 days.
`
`(21)
`
`Appl. N0.: 10/788,876
`
`(22)
`
`(65)
`
`Filed:
`
`Feb. 27, 2004
`
`Prior Publication Data
`
`US 2005/0108647 A1
`
`May 19, 2005
`
`Related US. Application Data
`
`<60)
`
`Provisional application No. 60/450,991, filed on Feb.
`28, 2003.
`
`Int. Cl.
`
`<51)
`
`(52)
`
`(58)
`
`(2006.01)
`G06F 3/048
`(2006.01)
`G06F 3/00
`US. Cl.
`....................... 715/744; 715/778; 715/779;
`715/746; 715/747
`Field of Classification Search ................. 715/744,
`715/778, 779, 747, 746
`See application file for complete search history.
`
`Hunter et al., “Java Servlet Programing”, Apr. 2001, 19 pages, 2nd
`Edition.
`
`(Continued)
`
`Primary ExamineriDennis-Doon Chow
`Assistant ExamineriAnil N Kumar
`(74) Attorney, Agent, or FirmiFlicslcr Mcycr LLP
`
`(57)
`
`ABSTRACT
`
`A method for rendering a portal graphical user interface
`(GUI), comprising providing for the representation of a GUI
`desktop, a GUI look and feel, and a GUI book as a set of
`controls wherein the controls can be organized in a logical
`hierarchy, traversing the representation, wherein the travers-
`ing compriscs associating a theme with a first control in the
`set of controls, rendering the first control according to the
`theme, rendering any descendents of the first control accord-
`ing to the theme, wherein any descendents of the first control
`can override the theme, and wherein one ofthe set of controls
`can communicate with another of the set of controls.
`
`40 Claims, 9 Drawing Sheets
`
`Process Ream
`.3121
`Map0 Requesrtoa
`antral Tree
`Famry
`302
`General! a Control
`Tree from the
`Factory
`304
`Evahatn the
`Control Tn» based
`on
`the Requem
`
` Done
`306
`
`Provide a
`Response
`
`Page 1 of 25
`
`GOOGLE EXHIBIT 1032
`
`Page 1 of 25
`
`GOOGLE EXHIBIT 1032
`
`

`

`US 7,814,423 B2
`
`Page 2
`
`U. S. PATENT DOCUMENTS
`
`
`
`711115243 131*
`7.155,678 B2 *
`7.203909 B1 *
`7.548,946 B1 *
`2001/0037287 A1
`2002/0118226 A1
`2002/0188729 A1
`2003/0014442 A1
`2003/0023628 A1
`2003/0055868 A1
`2003/0126558 A1
`2004/0098360 A1
`2004/0125124 A1
`2004/0133660 A1
`2006/0282451 A1
`
`~~~~~~~~
`
`..
`
`715/744
`. 715/744
`715/765
`.......... 709/203
`
`6 Ballard et 31'
`9/2
`6 Cooper et a1.
`12/2
`7 HOI'VItZ et 31'
`4/2
`9 Saulpaugh et a1.
`6/2
`1 Broadbent et a].
`11/2
`2 Hough et al.
`8/2
`2 Zh-ou'et 3L
`12/2
`“2 3 Shllgl et a1.
`1/2
`3 Girardot et a1.
`3/2
`3 Fletcher et a1.
`7/2
`3 Griffin
`5/2
`4 Witwer et a1.
`7/2
`4 Kim et a1.
`7/2
`4 Junghuber et a1.
`12/2
`6 Zhang etal.
`
`
`
`
`
`Hunter, “Java Seivlet Programming”, 2001, pp. 261-267, O’Reilly &
`Co.
`Hunter, “Java Servlet Progrannning”, 1998, 27 pages, O’Reilly,
`Copyright 2001.
`Knudsen. et al.. “Learning Java”. May 2000. 48 pages. O’Reilly &
`Associates, Inc.
`Hunter, “Java Servlet Programming”, 1998, pp. 485-486, O’Reilly,
`Copyright 2001.
`Meckler, “Java and Inter-Applet Communication”, Oct. 1, 1997, 11
`pages. Dr. Dobb’s Journal. htm://www.ddj.com/java/l 84410295.
`Geary, “Graphic JAVA Mastering the JFC”, 1999. 10 pages, Sim
`Microsystems, Inc.
`Bontrager. “Creating A '1'ab Panel”, Bontrager Connection LLP,
`2006, 10 pages. Retrieved from http://willmaster.com/library/tutori-
`alS/Creatingmaimbipanel-PhP-
`Andersen, “mhtTabPane”, 2002, 10 pages. Retrieved from http://
`users.cybercity.dld~dsl58854/articles/mhaTabPane.html, http://us-
`ers.cybercity.dk/~d5158854/a1ticles/mhaTab/readine.html.
`S h'ldt. Th C
`1 t R f
`, 2002.
`. 654-656, F'fth Ed.,
`McGraw Hill/Osborne.
`° 1
`'
`e
`(”up e e
`e erence
`' pp
`1
`
`OTHER PUBLICATIONS
`
`Moss, “JavaSeerets”, 1999, 26 pages, McGraw-Hill.
`
`* cited by examiner
`
`Page 2 of 25
`
`Page 2 of 25
`
`

`

`US. Patent
`
`Oct. 12, 2010
`
`Sheet 1 019
`
`US 7,814,423 B2
`
`QHECKING ACQOUN ! S
`
`XXXX - $XXX.XX
`
`XXXX - $XXX.XX
`
`XXXX - $XXX.XX
`
`Figure 1
`
`Page 3 of 25
`
`Page 3 of 25
`
`

`

`US. Patent
`
`Oct. 12, 2010
`
`Sheet 2 019
`
`US 7,814,423 B2
`
`AppIication
`200
`
`Look & Feel
`210
`
`Skeleton
`222
`
`
`
`
`
`
`Page 4 of 25
`
`Page 4 of 25
`
`

`

`US. Patent
`
`Oct. 12, 2010
`
`Sheet 3 of 9
`
`US 7,814,423 B2
`
`Process Request
`
`
`
`
`
`Map Request to a
`Control Tree
`
`Factory
`
`Generate a Control
`
`Tree from the
`
`Factory
`
`
`Evaluate the
`Control Tree based
`
`on the Request
`
`
`
`
`Provide a
`
`Response
`
`Figure 3
`
`Page 5 of 25
`
`Page 5 of 25
`
`

`

`US. Patent
`
`Oct. 12, 2010
`
`Sheet 4 of9
`
`US 7,814,423 B2
`
`———>
`
`
`Request 410
`'esponse 412 Container
`
`400
`
`Context
`
`408
`
`Figure 4
`
`Page 6 of 25
`
`Page 6 of 25
`
`

`

`US. Patent
`
`Oct. 12, 2010
`
`Sheet 5 0f 9
`
`US 7,814,423 B2
`
`JSP Parser Variant
`504
`
`Standard JSP Compiler
`506
`
`.JSP Page
`Impl.
`510
`
`
`
`
`
`Instantiation
`Service
`512
`
`Request 516
`
`Response 518
`
`Page 7 of 25
`
`Figure 5
`
`Page 7 of 25
`
`

`

`US. Patent
`
`Oct. 12, 2010
`
`Sheet 6 of9
`
`US 7,814,423 B2
`
`600
`
`Response 612
`
`Wireup Generator
`606
`
`Standard JSP Compiler
`608
`
`Request 510
`
`Instantiation
`Service
`614
`
`Figure 6
`
`Page 8 of 25
`
`Page 8 of 25
`
`

`

`US. Patent
`
`Oct. 12, 2010
`
`Sheet 7 of9
`
`US 7,814,423 B2
`
`/ 704
`doStartTag()
`getContmITreeO
`) / 708
`
`CreateContext(
`
`/ 706
`
`doEndTag() \ 712
`
`RunLifecycleToCompleteO
`
`/ 710
`
`Figure 7
`
`700
`
`Request 714
`
`4——-——
`Response 716
`
`Page 9 of 25
`
`Page 9 of 25
`
`

`

`US. Patent
`
`Oct. 12, 2010
`
`Sheet 8 of9
`
`US 7,814,423 B2
`
`Interchangeable
`Lifecycle Driver
`804
`
`Interchangeable
`Persistence Driver
`806
`
`800
`
`Porlet Container
`802
`
`Control Factory
`808
`
`Control Tree Container
`
`Request
`
`Response
`
`Client
`
`810
`
`Figure 8
`
`Page 10 of 25
`
`Page 10 of 25
`
`

`

`US. Patent
`
`Oct. 12, 2010
`
`Sheet 9 of9
`
`US 7,814,423 B2
`
`<%@page
`import="com.bea.netuix.servlets.controls.window.WindowPresentationContexticom.bea.netu
`ix.servlets.controls.window.TitlebarContexf'
`%>
`
`<%@ taglib un'="render.tld" prefix="render' %>
`<% WindowPresentationContext window =
`
`WindowPresentationContextgetWindowPresentationContext(request);
`Titleba rContext titlebar
`
`= (TitlebarContext) window.getFirstChi|d("window:tit|ebar");
`Stn‘ng expandWidth = "100%";
`%>
`
`<renderzbeginRender>
`<div
`
`<render:writeAttribute name="id" value="<%= window.getPresentationld() %>"/>
`<render:writeAttribute name="class" value="<%= window.getPresentationClass() %>"
`defaultVa|ue="bea—portal-window"/>
`<render:writeAttribute name="style" value="<%= window.getPresentationStyleO %>"/>
`<render:writeAttribute name="width"
`
`value="<%= window.isPacked() ? null : expandWidth %>"/>
`
`> <
`
`% if (titlebar != null){ %>
`<renderzrenderChild preSentationContext="<%= titlebar %>"/>
`<% } %>
`<div class="bea-portaI-window-content">
`</render:beginRender>
`<render2endRender>
`</div>
`</div>
`</render:endRender>
`
`Figure 9
`
`Page 11 of 25
`
`Page 11 of 25
`
`

`

`US 7,814,423 B2
`
`1
`METHOD FOR PROVIDING A GRAPHICAL
`USER INTERFACE
`
`CLAIM OF PRIORITY
`
`This application claims priority from the following appli—
`cation, which is hereby incorporated by reference in its
`entirety:
`U.S. Application No. 60/450,991, FRAMEWORK FORA
`PERSONALIZED PORTAL, Inventors: Daryl Olander, et a1 .,
`filed on Feb. 28, 2003.
`
`COPYRIGHT NOTICE
`
`A portion of the disclosure of this patent document con-
`tains material which is subject to copyright protection. The
`copyright owner has no objection to the facsimile reproduc-
`tion by anyone of the patent document or the patent disclo—
`sure, as it appears in the Patent and Trademark Office patent
`file or records, but otherwise reserves all copyright rights
`whatsoever.
`
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`
`This application is related to the following co-pending
`applications which are each hereby incorporated by reference
`in their entirety:
`L .8. application Ser. No. 10/788,803, Inventors: Scott
`Musson, et al., filed on Feb. 27, 2004, SYSTEM AND
`
`METI IOD FOR CONTAINING PORTLETS.
`L .S. application Ser. No. 10/788,530, Inventors: Scott
`Musson, et al., filed on Feb. 27, 2004, METHOD FOR ENTI-
`
`TLI\IG A USER INTERFACE.
`L.S. application Ser. No. 10/789,970, Inventors: Daryl B.
`Olander, et al., filed on Feb. 27, 2004, GRAPHICAL USER
`INTERFACE NAVIGATIOV METHOD.
`
`L.S. application Ser. No. 10/789,016, Inventors: Daryl B.
`Olander, et al., filed 011 Feb. 27, 2004. METHOD FOR UTI-
`LIZING LOOK AND FEEL I\I A GRAPHICAL USER
`INTERFACE.
`
`
`
`L .S. application Ser. No. 10/788,801. Inventors: Scott
`lV'usson, et al., filed on Feb. 27, 2004, METHOD FOR PORT-
`LET INSTANCE SUPPORT IV A GRAPHICAL USER
`
`INTERFACE.
`
`
`
`
`
`
`
`L.S. app ication Ser. No. 10/789,135, Inventors: Daryl B.
`
`Olander, et al., filed on Feb. 27, 2004, CONTROL-BASED
`
`GRAPHICAL USER INTERFACE FRAMEWORK.
`
`L.S. app ication Ser. No. 10/789,140. Inventors: Daryl B.
`Olander, et al., filed on Feb. 27, 2004, SYSTEM AND
`METHOD FOR DYNAMICALLY GENERATING A
`GRAPHICAL USER INTERFACE.
`
`I .S. app ication Ser. No. 10/789,137 Inventors: Daryl B.
`Olander, et al., filed on Feb. 27, 2004, METHOD FOR
`PROPAGATING LOOK AND FEEL IN A GRAPHICAL
`USER INTERFACE.
`
`BACKGROUND
`
`Developing graphical user interfaces (GUIs) for distrib-
`uted applications such as web portals can present many chal-
`lenges. Not only do end—users expect to customize the content
`a given GUI presents to them, they might also expect to
`customize the look and feel of the GUI. Such customization
`can be coarse-grained, as in changing an overall color
`scheme, but they can also be fine—grained wherein an end—user
`may desire to change the textures, arrangement, behaviors
`
`Page 12 of 25
`
`2
`and other characteristics of the GUI. This presents many
`design challenges, especially if such a GUI is deployed in a
`clustered, multi-threaded runtime environment.
`
`FIELD OF THE DISCLOSURE
`
`The present disclosure relates generally to graphical user
`interface development.
`
`
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`
`
`FIG. 1 is an illustration of an exemplary web graphical user
`interface in accordance to an embodiment.
`FIG. 2 is an illustration of a web control taxonomy in
`accordance to an embodiment.
`FIG. 3 is an illustration ofrequest processing in an embodi-
`ment.
`
`FIG. 4 is diagram of container processing in accordance to
`one embodiment.
`FIG. 5 is diagram of a control tree factory having a .1SP
`page description implementation in accordance to an embodi-
`ment.
`
`FIG. 6 is diagram of a control tree factory having a meta—
`data page description implementation accordance to an
`embodiment.
`
`FIG. 7 is diagram ofa control tree factory having a pure .1 SP
`page description implementation accordance to an embodi-
`ment.
`
`FIG. 8 is a diagram ofa system in accordance to an embodi-
`ment.
`
`FIG. 9 is a sample skeleton JavaServer Page in accordance
`to an embodimen .
`
` DETAILED DESCRIPTION
`
`The invention is illustrated by way of example and not by
`way of limitation in the figures ofthe accompanying drawings
`in which like references indicate similar elements. It should
`be noted that references to “an” or “one” embodiment in this
`
`disclosure are not necessarily to the same embodiment, and
`such references mean at least one.
`FIG. 1 is an illustration of an exemplary web graphical user
`interface in accordance to one embodiment of the invention.
`
`In one embodiment, by way of example, page 16 is rendered
`upon display area 12, which can be a region in the display area
`of a device for displaying images and/or producing sounds
`(e.g., a computer monitor). Page 16 is comprised of several
`elements. Page selection tabs 20-28 can each be selected by a
`user to render a different page. Pages can be thought of as
`panels or panes that can be swapped into and out of a display
`region of the available portal real estate. By way of a non-
`limiting example, selection of a GUI element can be accom-
`plished with an input device such as a mouse, a motion detec-
`tor, voice commands, hand or eye gestures, etc. If tab 20 were
`selected, for example, the page corresponding to that tab
`could be rendered. Although the tabs 20-28 in FIG. 1 are
`displayed horizontally, in another embodiment the tabs could
`be displayed vertically or using some other suitable scheme
`such as a hierarchical menu.
`
`Within page 16 is display area 10, which includes portlets
`(18, 3 0, 32) and other elements. A portlet is an application that
`manages its own GUI. Portlets can communicate with each
`other and with other software and hardware components (e. g.,
`Enterprise Java BeansTM, JavaTM Beans, servlets, applets,
`etc.). The JavaTM programming language, its libraries, envi-
`ronment, and toolkits are available from Sun Microsystems,
`Inc. of Santa Clara, Calif. The other software and hardware
`
`10
`
`15
`
`20
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Page 12 of 25
`
`

`

`US 7,814,423 B2
`
`3
`components may be part of the same execution environment
`as the portlet or may be in a different execution environment.
`In one embodiment, a portlet can be implemented with Jav-
`aServer Pages”. By way of a non-limiting example, portlet
`30 displays real-time stock ticker information. A user could
`configure such a portlet to display certain stocks, for example.
`In another embodiment, the user can select a given stock
`displayed in portlet 30 and receive more detailed information,
`such as the price history, price to earnings ratio, etc.
`Portlet 30 can handle user input and responding accord—
`ingly. Portlet 32 displays up-to-date infonnation pertaining to
`a user’s checking accounts. likewise, portlet 32 could pro-
`vide detailed information on transactions if the user were to
`select an account. Advcrtiscmcnt portlct 18 displays an advcr-
`tisement that could be directed specifically to the current user
`based on demographics or other information. For instance, if
`a user had an outstanding home loan in good standing, the
`advertisement could be for a home equity loan. Likewise, if
`the user had an appropriate amount in a savings account, the
`advertisement could be for a new car loan. Static area 14
`
`contains text or an image with text.
`FIG. 2 is an illustration of a control taxonomy in accor-
`dance to an embodiment. One embodiment provides a set of
`controls that represent corresponding graphical and func-
`tional clcmcnts in wcb applications. Controls can have prop-
`erties that can be read and set, and controls can interact with
`each other through an event notification mechanism. In addi-
`tion to properties and events, controls can also have methods
`which provide services and which may be overridden to pro-
`vide specialization of the control. In one embodiment, a con-
`trol can be implemented as one or more classes in an object-
`oriented programming paradigm. Such an arrangement
`allows for new properties, events and/or specialized control
`methods to be provided by extending base control classes
`related to these features. In a framework, controls can also
`serve as containers for other controls. By way of a non—
`limiting example, a page may contain a booklet and a portlet,
`the booklet may contain one or more pages, the portlet may
`contain a window, the window may contain a title bar which
`may contain a close button, etc.
`At the top of the taxonomy, there can be one or more web
`applications 200. A web application represents a collection of
`resources and components that can be deployed as a unit in
`one or more web/application servers. In one embodiment, a
`
`web application can represent a J23E (Java 2 Platform, Enter-
`prise Edition) Enterprise Application. In various embodi-
`ments, a web application can contain one or more controls
`202 representing one or more portals. From an end-user per-
`spective, a portal is a website whose pages can be navigated.
`From an enterprise perspective, a portal is a container of
`resources and functionality that can 3e made available to
`end-users. Portals can provide a point of access to applica-
`tions and information and may be one ofmany hosted within
`a web/application server. In one embociment, a portal can be
`
`a JZEE application consisting of EJB (Enterprise Java Bcan)
`components and a set of Web applications.
`In another
`embodiment, a portal can be defined by an XML (Extensible
`Markup Language) file. The portal file can contain all of the
`components that make up that particular instance, such as
`booklets, pages, portlets, and look and feel components.
`A GUI can contain one or more desktop controls 204. A
`desktop control in turn can contain one or more personalized
`views or user views (not shown). A user can have one or more
`personalized user views of a desktop. In one embodiment, a
`user view can result from customizing the layout, content,
`number, and appearance of elements within a desktop. A
`default user View can be provided for users who have not yet
`
`
`
`10
`
`15
`
`20
`
`30
`
`35
`
`40
`
`45
`
`50
`
`60
`
`65
`
`4
`customized a desktop. A desktop’s appearance can be deter-
`mined by a Look and Feel control 210. The look and feel
`control can contain a skin component 220 and a skeleton
`component 222. Skins can provide the overall colors, graph-
`ics, and styles used by all components in a desktop interface.
`In one embodiment, skins can include collections of graphics
`and cascading style sheets (CSS) that allow changes to be
`made to the look and feel ofthe GUI without modifying other
`components directly. References to images and styles can be
`made in the skin rather than being hard—coded into a GUI
`definition. A look and feel component can provide a path to a
`skin directory to be used.
`The look and feel file can also provides a path to the
`skeleton directory to be used. Every type of component, from
`a desktop to a portlet’s title bar, can have an associated JSP
`(Java ScrvchagcsTM) file, called a skeleton filc, that renders
`it. For example, each desktop uses a skeleton file called shell-
`.j sp that simply provides the opening and closing <HTML>
`(Hypertext Markup Language) tags to render the desktop. A
`portlct title bar, on the other hand, can have a skeleton file
`called titlebar.j sp 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 IITML table defini-
`tion.
`
`A desktop also can contain a booklet control 206. A booklet
`control represents a set of pages linked by a page navigator
`(menu 214) having a user selectable graphical representation
`(e.g., a series of tabs wherein each tab corresponds to a
`different page, a series of buttons, a menu, or other suitable
`means.) A booklet can provide an indication of the currently
`selected page through visual clues such as highlighting a
`currcntly sclcctcd tab, displaying tcxt and/or graphics to indi-
`cate the current page, etc. Booklets can be nested to 11 levels.
`A booklet can optionally include a theme control 212. In one
`embodiment, a theme control represents a subset of a skin
`component and can provide a way of using a different set of
`styles for individual desktop components. The booklet con-
`trol can also contain other booklets 216.
`
`A shell control 208 can render anything surrounding the
`booklet 206 in the desktop 204. For example, a shell control
`might render a desktop’s header and footer. These areas usu—
`ally display such things as personalized content, banner
`graphics, legal notices, and related links.
`A booklet also contains zero or more page controls 218. A
`page control can represent a web page in an embodiment. A
`page is an area of a GUI upon which other elements having
`GUIs, such as booklets and portlets, can be placed. Pages can
`also contain booklets and other pages, and can be identified/
`navigated to by a control such as a menu 214. A page control
`can also hold a theme control 224 and a layout control 226. A
`layout control dctcrmincs thc physical locations of portlcts
`and other elements on a page. In one embodiment, a layout is
`can be implemented as an HTML table.
`A layout can contain a placeholder control 228 which is
`comprised of individual cells in a layout in which portlets are
`placed. A placeholder can contain zero or more booklets 232
`and zero or more portlcts 230. A portlet is a self-contained
`application that can render its own GUI. A portlet is a self-
`contained application that is responsible for rendering its own
`content on a page. By way ofa non—limiting example, a portlet
`might be a display ofcurrent news headlines, wherein ifa user
`selects a headline the portlet retrieves and the underlying
`story and displays it for the user. Portlets can communicate
`with other portlets and with back—end processes such as
`legacy software. databases, content management systems,
`
`Page 13 of 25
`
`Page 13 of 25
`
`

`

`US 7,814,423 B2
`
`6
`made to data and raise events before either redirecting to a
`new page or simply displaying the same page again. In one
`embodiment, multiple control scopes can be provided as
`described in Table l.
`
`5
`
`TABLE 1
`
`5
`In addition, multiple
`enterprise business services, etc.
`instances of a portlet can execute simultaneously. A portlet
`can also contain a theme 234.
`A control tree can represent a particular instance of the
`control taxonomy. In one embodiment, each node in the con-
`trol tree can be a subclass of a Control class in an object—
`oriented paradigm. A control tree can be created with both
`statically created controls and dynamically created controls. #MW
`Statically created controls are created during a construction
`SCOPE
`DESCRIPTION
`(or Wire—up ) phase of the control tree and, in one einbodi— to
`ment, can be based 011 static markup. Dynamically created
`quucst
`An object is accessiblc forthc life offllcl‘equcst-
`controls are created during a control tree lifecycle, manv
`Fag“
`A“ ObJCCt is “COSMIC aim“ SUbSCunHt requests
`.
`.
`.
`.
`" a
`to a page. In one embodiment, a page has a lifetime
`times in reaction to state, context, and events. Both kinds ot
`Hm can include a postback cycle.
`contrOIS can create content Clthcr dynalnlcally (Cg; by blnd'
`An object is accessible for the life ofthe session. (This is
`ing to a database table) or statically (e.g., by containing a 15
`availablc for protocols that SUPPOIL 568510113)
`.
`.
`.
`webfiow. A Webflow is a set ofstates that control
`literal SlI‘iIlg).
`An object is accessible Within a named scope defined by a
`.
`.
`r 9 ion rom one we page to another.
`.
`.
`Controls Within a control tree can have unique names. In
`m“ ”at.
`f
`b
`addition, CODUOIS can have local names that are quahfied Into
`Application An object is accessible globally Within the application.
`a scope. This can allow for controls to be searched for based
`upon their “local” name within a naming scope. In one 20
`embodiment, the system can use a eontrol’s unique name for
`identifying it in operations such as saving and restoring state
`during the cycle of HTML postbacks to the page. Postback
`occurs when a form on a page targets the same page. When the
`form is submitted, the second request for the page is called a 25
`postback. The po stback allows the page to handle changes
`
`Session
`
`Webflow
`
`.
`In one embodiment, many ofthe classes can be sub-classed
`to provrde specralizations and custom teatures. It W111 be
`apparent to those skilled in the art that many more such
`classes are within the scope and spirit of the present disclo-
`sure. Table 2 provides an overview of classes in one embodi-
`ment.
`
`TABLE 2
`
`Framewori Controls in an Embodiment
`
`CLASS/
`INTERFACE
`
`Control
`
`Lifecycle
`
`NamingScope
`
`Context
`
`Page 14 of 25
`
`
`
`DESCRIPTION
`
`
`
`
`
`The basic rarnework auilding block. The base Control class
`defines a set of services available to all controls. This class
`defines an provides a set of services to su Jclasses including
`lifecycle, naming, an child management.
`A lifecycle driver wil drive the controletree through a well
`defined set ofstates. For a control, the lifecycle is defined by a
`set of methods representing stages in the li ecycle. A control
`can overri e methods of the lifecycle in or er to provide
`specialize behavior. :or example, most controls Will override
`beginRen er to render its specific representation to an output
`stream. The stages provide well defined places to acquire
`resources, manage state, raise events, render themselves, etc.
`Most lifecycie stages consist oftwo metho s that are called by
`the lifecyc e driver. T ie naming pattern of ie two ineLhods is
`Xxxx and ‘ireXxxx. The Xxxx method is overridden by
`subclasses to specialize the lifecycle stage. The fireXxxx
`method is overridden if a control wants to c ange how the event
`associated with the li ecycle stage is fired.
`Defines methods called during the controls lifecycle. There are
`two methods for most lifecycle events. The ifecycle method
`xxx is called first to provide the lifecycle service for the control.
`Then an onXxx method is called to raise an event. In one
`embodiment, all ofthe Iifecycie stages prior to rendering raise
`events through the onXxx method.
`The Control and the NamingS cope interface interact to provide
`support for uniquely naming a control within a tree. Unique
`names are generated automatically when controls are added to
`an existing control-tree. Unique names are used for state
`management. Controls have three types ofnarnes:
`Id - This is a user assigned value that should be unique within a
`name scope.
`Scopeld - This is a generated name that is unique within a
`scope. It is either the Id or a generated name.
`UniqueId - This is the globally unique name of the control.
`This name is typically used to identify state and identify the
`control Within a HTML Form.
`Context is an abstract class providing services to controls in Lhe
`tree. In one embodiment, these services are protocol-
`independent. It is the container’s responsibility to create the
`context object. The container can create an object that
`
`Page 14 of 25
`
`

`

`US 7,814,423 B2
`
`7
`
`TABLE 2-continued
`
`Framework Controls in an Embodiment
`
`CLASS/
`INTERFACE
`
`DESCRIPTION
`
`subclasses (Iontext and provides container aware controls with
`additional services such as information about the framework and or protocol.
`By way ofa non-limiting example, a container can be a servlet
`providing a framework. The Context can contain both HTTP-
`specific information and web application-specific information.
`A Portlet control that is portal-aware can cast the Context into
`the subclass and access these services. Well-designed controls,
`Which are aware of one or more containers, can be written to
`work or fail gracefully when they are used within the context of
`the generic Context.
`Context provides the following services:
`Access to the Abstract Data Layer - Context will provrde an
`object implementing the interface providing an abstract data
`layer.
`55
`.E
`Request Type 7 The Context contains properties indicating what
`type of request is happening such as “new request , postback”,
`etc.
`Request Information - The Context provides information that
`comes from the request such as request parameters, requested
`URL, etc. This information may be unavailable for protocols
`that don’t support it.
`Generic Services - The context allows controls to access and
`register as service providers to other controls. For example, a
`StyleBlock control may register as the StyleHandler object that
`will create a single style sheet for an output HTML document.
`Other controls may push style definitions into the StyleHandler.
`These services will typically be used by a set of framework
`aware controls and will support firings such as styles, URL
`rewriting, etc.
`Renderer is an interface that allows a class to be created and
`which acts as a rendering proxy for a control. A control has
`rendering methods allowing the control to output is
`representation into a stream. There are two primary methods for
`rendering; beginRender( ) and endRender( ). Default rendering
`can be overridden by setting a control’s renderer by providing
`an obj ect implementing the Renderer interface.
`
`Renderer
`
`45
`
`FIG. 3 is an illustration ofrequest processing in an embodi-
`ment. Although this figure depicts functional steps in a par- 40
`ticular order for purposes of illustration, the process is not
`limited to any particular order or arrangement of steps. One
`skilled in the art will appreciate that the various steps por-
`trayed in this figure could be omitted, rearranged, combined
`and/or adapted in various ways.
`In one embodiment, a GUI is rendered in response to a
`request (e.g., an HTML request originating from a web
`browser). In step 300, a process (e.g., a web/application
`server or other suitable process) can accept the request and
`map it to a control tree factory. In step 302, the identified 50
`factory can be used to generate a control tree representing the
`GUI. In step 304, the control tree can be evaluated based on
`the contents of the request. In doing so, the control tree can be
`driven through a sequence of lifecycles that allow for indi-
`vidual controls in the tree to, by way of a non—limiting 55
`example, process the request, interact with each other and a
`context provided by the container, and produce a response.
`Finally, in step 306 the process can provide a response to the
`sender of the request. In one embodiment, this response can
`contain output for GUI rendering (e.g., HTML or other suit-
`able GUI description) from one or more controls.
`In one embodiment a container (not shown) can run the
`control tree through a sequence of one or more lifecycles by
`employing the services of an interchangeable lifecycle driver
`(not shown). In one embodiment, a control or a container can 65
`customize the lifecycle. Customization can include removing
`and/or reordering defined lifecycle stages and/or adding new
`
`60
`
`stages. All of the controls in the control tree can participate in
`the lifecycle, but do not have to. The purpose of the lifecycle
`is to advance the control tree though a set of states. These
`states permit controls to obtain their state and resources, raise
`and handle events, save their state, communicate with other
`controls, render themselves, and free resources. The lifecycle
`is external to the control tree and can be provided by the
`container. This allows for easy modification of the lifecycle.
`In one embodiment, controls can register to raise and catch
`events to perfect
`inter-control communication. An event
`mechanism allows controls to specify (or register for) events
`that they will raise and/or listen for. In one embodiment. this
`can be accomplished with two methods. A method named
`“xxxx” represents the lifecycle method itself and is usually
`sub-classed to provide specialized behavior for the control.A
`method named “fireXxxx” can be invoked to cause an event
`
`notification that the lifecycle method xxxx has run on the
`control. This method can be overridden to provide specializa-
`tion of event firing. By way of a non—limiting example, a
`control could suppress firing of an event by overriding it and
`doing nothing. When an event is raised, all controls that have
`registered to receive it will be given an opportunity to handle
`the event (e. g., through a call—back mechanism). There is no
`limit on the number of events that can be raised or caught. By
`way of a non-limiting example, a form control could raise an
`event when a user enters text in a text field of a GUI repre-
`sentation of the form. This event could be caught by a button
`011 the same page as the form. The button could then un—dim
`
`Page 15 of 25
`
`Page 15 of 25
`
`

`

`US 7,814,423 B2
`
`9
`itself based on a determination of whether a user entered a
`valid character sequence into the form.
`Controls can be dynamically added to the tree at any stage
`of the lifecycle up until a pre-render stage. When controls are
`added to an existing tree dynamically, these new controls can
`participate in the full lifecycle. In one embodiment, a life—
`cycle catch-up process can drive the new controls through the
`lifecycle until they catch-up to the current stage. All lifecycle
`stages before the rendering stage can raise events. In one
`embodiment, a container can implement the lifecycle stages
`illustrated in Table 3.
`
`TABLE 3
`
`Lifecycle Stages in an Embodiment