Portals Design Documentation
by
Tarik Alatovic
I. Essentials
II. Introduction
Big Picture
Arsdigita portals solve two major problems of presenting information to the users:
- Aggregating information from organization's internal and external data sources
- Customization of information content and layout through personal and group portals
As above figure shows, portals are an interface between the information content distributed among multiple databases and clients who are presented with the information relevant to them.
System Components
The portal system is built out of five entities:
- portals
- portal domains
- portal pages
- portlets
- portlet data feeds
Portal is a user interface that presents information collected from multiple data sources to the user. Every portal belongs to either user or a group. User portals aggregate information that is personalized for user's needs. Group portals aggregate information that is of interest to group member.
Portal domain is a collection of portals that share the default
configuration, display settings, and authorization procedures. One
portal domain can be defined for all of the user portals, and one
portal domain can be defined for each of the group types, such as,
suppliers and customers.
Portal page is a component of the portal corresponding to a
single web page. Every portal consists of one or more portal pages.
(screenshot of typical portal page)
Portlet is a user interface component displaying information that has
something in common. For example, the announcement portlet displays
the latest news headlines. Every portal page consists of one or more
portlets. (screenshot of typical
portlet)
Portal data feed is a piece of tcl or adp code that generates content
to be served inside the portlet. This code connects to internal or
external database, retrieves the data, and returns the information
user is interested in.
What are the potential uses of portals package
Arsdigita portals package has already been used to build a wide spectrum of web applications. Portals ASJ article presents three case studies of web services where portals were used as a solution for data aggregation and personalization:
Case 1: my.caltech.edu
my.caltech.edu is university portal build for Caltech University. Portals were used for two main purposes: (1) aggregation of data from multiple department servers, and (2) customization of aggregated data to best match the needs of different classed of users (professors, students, and alumni).
Case 2: sloanspace.mit.edu
sloanspace.mit.edu uses Arsdigita education solution. sloanspace.mit.edu uses both user and group portals.
Group portals are used to aggregate class data: (1) class schedule, (2) lecture notes, (3) assignments, (4) staff list, and all the other class data. Professors who are administrators of class portals can easily customize the class portal page, so that it matches specific needs of their class.
User portals are used to aggregate data the student is interested in: (1) assignments from all of the student classes, (2) calendar of events with integrated class calendars, (3) announcements from all the classes, (4) links to class portals, and all the other student data.
Case 3: arsdigita.com
Arsdigita.com uses portals to provide its customers with company announcements, presentations, discussion boards, bug reporting tool, and all the other information relevant to customers.
High-level overview of how portals package meets its requirements
- Data model requirements are met by having a normalized data model corresponding to natural portal objects: portals, portal domains, portal pages, portlets, and portal data feeds.
- API requirements are met by implementation of object based API where procedures are defined for creating, destroying, modifying, and getting information about each of portal objects. In addition, procedures are provided for: getting information about currently served portal page, and generating portal graphic components.
- Usability requirements are met by having user and group portals automatically created and set to default the first time these portals are accessed
- Reliability and robustness requirements are met by catching errors thrown by code in portlets.
- Authorization requirements are met by implementation of mechanism for registration of domain specific authorization procedures. For each domain, a procedure can be registered that determines whether the user has a right to view or administer the portal.
III. Historical Considerations
Portal History
Aurelius Prozhacka built the original portal system in 1999 for
my.caltech.edu site where information was gathered from multiple
department servers and customized for different classes of users:
student, professor, and alumni. This initial implementation of
portals offered both user and group portals, and served as an
excellent prototype for the further development of portals.
During the summer of 2000, number of improvements to portal system was
implemented and new portals package v2.0 was born. Driving force
behind this new development of portal system was the development of
Arsdigita's education solution, which required a sophisticated portal
system. Moreover, during the time the education solution was
developed, two other web services were moving towards portals -- an
interface solving problems of data aggregation and personalization:
arsdigita.com and redbricks.com.
Portal Evolution from package v1.0 to v2.0
Here is the list of improvements made to versions 2.0, which were result of our need for more sophisticated portals solution and our experience using original version of portals:
New Functionality
- ACS modules running inside portals
How does it benefit users ?
- Default portal configurations
How does it benefit users ?
- users are presented with default portals configuration and are not
forced to customize portals from scratch (a tasks that only advanced
users would be interested in)
How does it benefit developers ?
-
it let developers quickly develop prototype UI and present it to the
client. Clients with no technical knowledge could easily alter the
user interface, so that it satisfies their needs.
- Automatic creation of group and user portals
-
a portal is created for a user first time he or she tries to access it
(take a look at default portal student gets first time she logs in
into the sloanspace.mit.edu)
- a portal is created for a group first time group portal is
accessed (take a look at default group portal student gets first time
he or she accesses course page for 15.065 at sloanspace.mit.edu)
- Portal can be reverted to default configuration
-
if users are not satisfied with their portal customization, they have option of reverting to default portal
- Elegant design
-
abstracted notions of portals, portal domains, and portal data feeds make code writing, maintenance, and future improvements easier.
-
revised data model makes transition to ACS4.0 relatively painless
- Excellent performance
-
virtually all portal data cached
- portal_data_feeds can now run tcl code (not only adp), resulting
in big performance improvement since using tcl data feeds avoids
running very expensive ns_adp_parse function
- Well defined and documented API
- portals is among the first packages that precisely defines its API
allowing for truly independent development cycles.
- Flexible portal URLs
-
root URL for portal domain can be changed from admin interface
-
user portals don't encode user_id in the URL anymore (typical user
portal URL is /home/page-2 for page 2 of user portal)
-
group portals are identified with short name (typical group portal URL
is /class/15.301/page-3 where "class" is url_root for this portal
domain, "15.301" is short name of a group, and page 3 of group portal
is served)
- Domain level display customization
- color of portlets can be customized on domain level giving uniform
look to portals belonging to the same domain
- Access control
- access procedure can be registered for each domain that defines
who has view and administer privileges over a portal
- Portals work with templating system
- portal data feed handles templating system adp
- Domain based ACS admin interface
- ACS administration is domain based giving ACS admin full control
over domains default portal configurations, display setting, and
authorization procedures
- Control panel
- portal can have optional control panel that cannot be customized like other portal pages, so that users can't mess it up no matter how hard they try. as it's name suggest, control panel is entry point for all administrative functions.
- here is how typical control panel looks like
- Required portlets
- Portlets can be identified as required in which case user cannot remove them through customization. This is important for robustness as some portlets are critical and we don't want user to remove them.
Dead Functionality
- Support for portal administration groups
- portal domains are now administered by ACS administrators
- group portals are now administered by group administrators
- user portals are now administered by users
IV. Competitive Analysis
The word portal is used for many different things. Numerous companies in the web market offer and define their own portal solutions. Oracle's portal solution is basically a site-building tool that allows a site administrator to create a site using an existing data model. Yahoo's portals are entirely different. They are a mechanism for providing Yahoo subscribers access to Yahoo's features, module and partners.
ACS portals integrate features of both Yahoo portals and Oracle portals and are a very good example of ArsDigita's B2B2C model. ACS portals provide both group portals aggregating business-oriented information and user portals aggregating information relevant to the user.
Comparison with Yahoo portals (my.yahoo.com)
ACS portals are like Yahoo portals in that they offer predefined portlets to view into existing data models. ACS portals also support user level customization and are intended as a tool for managing individual information flow. The current implementations of ACS portals solve similar problems to Yahoo portals.
It is important to note, however, that ACS and Yahoo portals are not actually competitors, as Yahoo supplies portals only for its subscribers. In contrast, ACS is an open source solution that allows anyone to build a portal system. Therefore, our comparison will be limited only to the tool used to create yahoo portals - not the yahoo service.
ACS Advantages
Main advantage of ACS over Yahoo portals is that ACS portals support user groups. As ACS has a complete view of the user, it is able to gather the data from all the groups the user belongs to and serve it in user's personal portal. ACS portals also make creation of groups easy providing groups with their "home" displaying data relevant to group members.
Yahoo Advantages
Yahoo portals have a significantly more flexible UI for user customization and better graphic design.
Comparison with Oracle portals
Like Oracle portals, ACS portals are a tool for site administrators to quickly and flexibly build a site. However, Oracle portals are a more general tool designed to work on any existing data model inside an oracle database, and ACS portals are tied directly to the ACS data model. Oracle also includes a powerful graphing capability as a part of portals package. This functionality is not a part of ACS portals but is handled by another ACS package instead.
ACS advantages
Because ACS portals are tied to the ACS data model, they offer several advantages:
- Portals follow the Arsdigita philosophy of distributed
administration. They allow the site administrator to collaborate with
group administrators to create the site. The site administrator
creates portlets and default portal configurations, providing group
administrators with components to design their own sections of the
site.
- The ACS user group concept provides advantages in customization
both at the user and group levels.
Oracle advantages
Oracle portals have powerful administrative UI for arranging portlets and tools for creating portlets from tables in the data model without programming. Layout and graphics are sophisticated and powerful.
Here is a high level feature overview comparing Arsdigita Portals, Oracle Portals, and my.yahoo.com.
| Feature
| Arsdigita Portals
| Oracle Portals
| my.yahoo.com
|
| Open source
| Yes
|
|
|
| Aggregating data from multiple data sources
| Yes
| Yes
| Yes
|
| Aggregating data from external data sources
| Yes
|
| Yes
|
|
Interface for writing portlets
| Yes
| Yes
|
|
| User portals
| Yes
| Yes
| Yes
|
|
Group portals
| Yes
|
|
|
|
Serving dynamic content
| Yes
| Yes
| Yes
|
|
Default user portals
| Yes
|
| Yes
|
| Default group portals
| Yes
|
|
|
|
Automatic creation of user portals
| Yes
|
| Yes
|
|
Automatic creation of group portals
| Yes
|
|
|
|
Portlet level access control
|
| Yes
|
|
|
Required portlets
| Yes
|
|
|
|
Remove portlet button
|
|
| Yes
|
| 2-column portal pages
| Yes
| Yes
| Yes
|
| 3-column portal pages*
|
| Yes
| Yes
|
| Changing display settings of individual portals
|
| Yes
| Yes
|
| Changing display settings on the domain level
| Yes
|
|
|
* YBOS wrote an extension of Arsdigita's portals supporting multiple columns of variable width. The next version of Arsdigita's portals is likely to incorporate this change
V. Design Tradeoffs
Performance
Portals provide two very important functions for the users: (1) they have links to all the information user is interested in and (2) they gather and serve information most relevant to the user. As a consequence, portal pages are accessed very frequently and need to have an excellent performance. In order to accomplish this performance goal, our implementation was aimed at bringing number of database queries portal system needs to perform to zero.
It is important to note, however, that the time to serve portal pages depends on two factors: (1) time to generate html that sets up the portal framework (all html except the content coming from data feeds inside portlets) and (2) time to generate html code inside portlets. Our performance design can only affect the first one, the time to generate portal framework html, as the second one depends on implementation of other packages that provide data feeds.
We decided to use shared variables as a caching mechanism and store all of the portal information in memory cache. This approach eliminated hits to the database that were necessary to generating portal framework html. While shared variables cache approach results in an excellent performance, it comes at a significant cost for two reasons: (1) it complicates the code, and (2) it prevents portal system from working on multiple machines as cache is not shared among these machines. One of the future enhancements of portal system is replacing existing shared variable caching with the caching subsystem of ACS4.1.
Portability
Portal system should be relatively easy to port to ACS4.0 because it abstracts users, groups, and user_group_types to only two tables: portals and portal_domains. In addition, portal API is very much object based matching the new architecture of ACS4.0.
One of our considerations in writing portals was portability to non-Oracle ACS implementations. In particular, we minimized the amount of PL/SQL used to allow easier port to Postgre database of OpenACS.
Interoperability
Portal system is a gateway that gathers information through various packages and serves it to the user. The way portal system integrates with other packages is by providing an interface for adding new portal data feeds that can be fed into portlets.
For example, the way we integrate calendar functionality into portals is to define a new calendar-portal package containing tcl code (data feed) that generates calendar html served from within portlets. In general, for each package we can define a binding portal-module package containing data feed for serving package information from within portals.
Usability
The portal interface is an intuitive one as information is grouped by its purpose for the user. In addition, the usability of portals has been greatly improved with the introduction of default portal configurations in version 2.0. Default portal configurations provide users with ready-to-use portals, and significantly lower the learning curve.
As for administration side, portals have a powerful admin interface giving ACS administrator a lot of freedom for configuration and modification of portals on the portal domain level.
Reliability and Robustness
Major reliability and robustness concern of portal system is that any error coming from the code running inside portlets must not affect user's ability to view information from all the other portlets. We achieved this by catching errors generated by code inside portlets and simply not showing error-causing portlets.
Flexibility and Reusability
Portals were designed to simultaneously satisfy demands of three different projects: education solution portals for classes and students, arsdigita.com portals for customers, and redbricks.com portals for community of real estate agents. Making portals work for three different clients forced us to make flexibility and reusability a top priority of our system design.
Three design choices were particularly important for achieving flexibility and reusability: (1) normalized and logical data model, (2) object-oriented API, and (3) providing mechanism for registering authorization procedures for each of portal domains.
Maintainability and Testability
Same design choices that helped us improve flexibility and reusability also helped us improve maintainability and testability. Normalized data model and well-defined object-oriented API resulted in two benefits: (1) less lines of code, and (2) more readable and understandable code.
VI. API
In order to offer maximum flexibility to developers using portals for user interface, we provide an object based API. With the object based API developers can create, destroy, modify, and get information about all of the portal objects: portals, portal domains, portal pages, portlets and portal data feeds.
Portal Domain API
portals_create_domain {type url_root {group_type ""} {admin_data_feed_id ""}}
Creates new domain, which can be either user domain for all the user portals, or a group domain for group type specified by group_type. Portal URL root for the new domain is specified by url_root. admin_data_feed_id is optional parameter that specifies data feed containing code for the control panel of the new domain. portals_create_domain returns domain_id of newly created portal domain.
portals_destroy_domain {domain_id}
Destroys domain identified with domain_id.
portals_set_domain_property {which value domain_id}
Sets the value of the domain property identified with which for the domain identified with domain_id, to the value given by value parameter.
portals_get_domain_property {which domain_id}
Returns the value of the domain property identified with which, for the domain identified with domain_id.
Portal API
portals_create_portal {domain_id id {portal_name ""}}
Creates new portal in the domain identified with domain_id. If the domain is user domain, the id is user_id of the to user to whom the portal belongs. If the domain is group domain, then id is group_id of the group to which the portal belongs. portal_name is optional parameter specifying name of the new portal. portals_create_portal returns portal_id of the newly create portal.
portals_create_default_portal {domain_id {portal_name}}
Creates default portal for the domain identified with domain_id. portal_name is optional parameter specifying name of the new portal. portals_create_default_portal returns portal_of newly created default portal.
portals_destroy_portal {portal_id}
Destroys portal identified with portal_id.
portals_set_portal_property {which value portal_id}
Sets the value of the portal property identified with which for the portal identified with portal_id, to the value given by value parameter.
portals_get_portal_property {which portal_id}
Returns the value of the portal property identified with which, for the portal identified with portal_id.
Portal Page API
portals_create_page {portal_id page_number {page_name ""}}
Creates portal page belonging to portal identified by portal_id. Page number specifies number of the page, which is unique for the portal that the page belongs to. page_name is optional argument specifying name of the portal page.
portals_destroy_page {page_id}
Destroys portal page identified with page_id.
portals_set_page_property {which value page_id}
Sets the value of the page property identified with which for the page identified with page_id, to the value given by value parameter.
portals_get_page_property {which page_id}
Returns the value of the page property identified with which, for the page identified with page_id.
Portlet API
portals_create_portlet { domain_id data_feed_id required_p portlet_name {link_url} }
Creates portlet for domain identified with domain_id, using portal data feed identified with data_feed_id. portlet_name is name of the portlet, which is unique for the portal domain to which the portlet belongs. required_p specifies whether portlet is required or not. Optional link_url parameter specifies URL where this portlet can be administered. portals_create-portlet returns portlet_id of newly created portlet.
portals_destroy_portlet {}
Destroys portlet identified with portlet_id.
portals_set_portlet_property {which value portlet_id}
Sets the value of the portlet property identified with which for the portlet identified with portlet_id, to the value given by value parameter.
portals_get_portlet_property {which portlet_id}
Returns the value of the portlet property identified with which, for the portlet identified with portlet_id.
Portal Data Feed API
portals_create_data_feed { data_feed_name predefined_p code_type code}
Creates portal data feed with unique data_feed_name. predefined_p specifies whether this data feed is predefined or user-defined. Predefined data feeds are defined only by developers and cannot be changes. User-defined data feeds are modifiable through ACS administrator interface. Code type is either tcl or adp.
portals_destroy_data_feed {}
Destroys portal data feed identified with data_feed_id.
portals_set_data_feed_property {which value data_feed_id}
Sets the value of the data feed property identified with which for the data feed identified with data_feed_id, to the value given by value parameter.
portals_get_data_feed_property {which data_feed_id}
Returns the value of the data feed property identified with which, for the data feed identified with data_feed_id.
User Interface widgets API
portals_portlet_html {portlet_id}
Returns portlet html. Portlet html consists of two parts: (1) portlet header displays portlet name and link to portlet administration page, and (2) portlet body display html obtained by evaluating portlet's data feed code.
portals_page_html {page_id}
Returns page html. Portal page consist of three parts: (1) header displays name of the portal, (2) navigation bar displays links to other portal pages, (3) body displays all portlets belonging to this page, and (4) footer displays link for contacting portal administrator.
portals_navigation_bar {page_id}
Returns navigation bar html for the page specified by page_id.
Authorization API
portals_user_has_permission_p {portal_id permission}
Returns 1 if logged in user has permission identified by permission parameter (view or administer).
portals_register_permission_proc {proc_name portal_type {group_type ""}}
Registers authorization procedure for portal domain. If portal type is user than procedure is registered for users portal domain. If portal type is group then authorization procedures is registered for the group domain identified by group_type.
Portal Info API
portals_info {which}
Returns property identified by which of currently served portal page. Property is one of the following: portal id, portal page id, portal type (user or a group), domain id to which the portal belongs, URL root of that domain, and whether user has administrative privilege for the portal.
VII. Data Model Discussion
Portals data model is normalized and tables in data model corresponding to natural portal objects: portals, portal data feeds, portal page, portlets, and portal data feeds.
Portal is a user interface that presents information collected from multiple data sources to the user. Every portal belongs to either user or a group. User portals aggregate information that is personalized for user's needs. Group portals aggregate information that is of interest to group member.
create table portals (
portal_id integer
constraint portals_portal_id_pk primary key,
domain_id constraint portals_domain_id_fk references portal_domains on delete cascade,
-- is portal page a default portal or a regular portal
default_p char(1) default 'f'
constraint portal_pages_default_p_ck check(default_p in ('t', 'f')),
portal_name varchar(300),
-- define ownership of the page - either as a group page, or individual''s page
-- one of (group_id, user_id) should not be null
group_id constraint portals_group_id_fk references user_groups on delete cascade,
user_id constraint portals_user_id_fk references users on delete cascade,
constraint portals_group_id_user_id_ck check(group_id is not null or user_id is not null),
constraint portals_group_id_user_id_un unique(user_id, group_id)
);
In order to simplify data model and write less code, we decided to keep the default portal configurations in the same table as regular portals. default_p column tells us whether a portal is a default or regular portal. user portal belongs to user identified by user_id. group portal belongs to group identified by group_id.
Portal domain is a collection of portals that share the default
configuration, display settings, and authorization procedures. One
portal domain can be defined for all of the user portals, and one
portal domain can be defined for each of the group types, such as,
suppliers and customers.
create table portal_domains (
domain_id integer
constraint portal_domains_domain_id_pk primary key,
type varchar(20)
constraint portal_domains_type_ck check (type in ('user','group'))
constraint portal_domains_type_nn not null,
group_type constraint portal_domains_group_type_fk
references user_group_types(group_type) on delete cascade,
url_root varchar(200)
constraint portal_domains_url_root_un unique
constraint portal_domains_url_root_nn not null,
admin_data_feed_id constraint portal_domains_adfi_fk references portal_data_feeds on delete set null,
constraint portal_domains_type_check_ck check ((type='user' and group_type is null) or (type='group' and group_type is not null)),
constraint portal_domains_unique_un unique(type, group_type)
);
One portal domain of type user can be defined for all user portals. One portal domain of type group can be define dfor every group type specified by group_type. url_root is the root URL used for generating portal URLs. admin_data_feed_id may store the data feed id containing the control panel code.
create table portal_domain_properties (
-- define data feed that supplies administration page
domain_id constraint portal_domain_props_di_fk
references portal_domains on delete cascade
constraint portal_domain_props_di_pk
primary key,
portlet_header_color varchar(20),
td_header_html varchar(1000)
);
Table portal_domain_properties stores various properties for a portal domain. It is in a separate table from portal_domains table because this table is likely to change as we add more domain level display settings in future releases of portals.
Portal page is a component of the portal corresponding to a single web
page. Every portal consists of one or more portal pages.
create table portal_pages (
page_id integer
constraint portal_pages_page_id_pk primary key,
portal_id constraint portal_pages_portal_id_fk references portals on delete cascade
constraint portal_pages_portal_id_nn not null,
-- page_name may be null, in which case we use "Page #x" instead
page_name varchar(300),
page_number integer
);
Each page belongs to portal identified by portal_id. Page name is optional pretty name for the page. Page number uniquely identifies a page for a given portal (page number is used as a part of portal URL).
Portlet is a user interface component displaying information that
has something in common. For example, the announcement portlet
displays the latest news headlines. Every portal page consists of one
or more portlets.
create table portal_portlets (
portlet_id integer primary key,
-- portlet_name is varchar(4000) because it may contain ADP
domain_id constraint portal_portlets_domain_id_fk references portal_domains on delete cascade
constraint portal_portlets_domain_id_nn not null,
-- is this a required portlet
required_p char(1) default 'f'
constraint portal_portlets_required_p_ck check(required_p in ('t', 'f')),
portlet_name varchar(4000),
-- data_feed tells us where to get the data served in this portlet
data_feed_id constraint portal_portlets_data_feed_fk references portal_data_feeds on delete cascade
constraint portal_portlets_data_feed_nn not null,
-- if you don't want administrators to have direct access to
-- the adp, admin_url should be not null
-- admin_url can be an adp and is used for the edit link
-- on the top of the portlet.
link_url varchar(1000),
creation_user integer references users(user_id),
modified_date date
);
domain_id identifies the domain to which this portlet belong. This means that the portlet can be used only in the portals that are a part of portal domain identified by domain_id. required_p column determined whether the portlet is required or not. Required portlets cannot be removed from portal configurations. Portal managers who try to remove a required portal are issued a complaint telling them that they can't remove a required portlet. data_feed_id identifies portal data feed that generates html content of the portlet. link_url is used for storing a portlet administration link.
create table portal_portlet_page_map (
-- page_id and portlet_id are mapped to one another her
page_id constraint portal_portlet_page_map_pi_fk references portal_pages on delete cascade
constraint portal_portlet_page_map_pi_nn not null,
portlet_id constraint portal_portlet_page_map_ti_fk references portal_portlets on delete cascade
constraint portal_portlet_page_map_ti_nn not null,
-- sort_key and page_side define location of the portlet on the page
-- this defines an order within this side of this page
sort_key integer,
-- side of the page the portlet will displayed on
page_side char(1)
constraint portal_portlet_page_map_ps_ck check (page_side in ('l','r'))
);
portal_portlet_page_map stores information about placement of portlets on the portal page. page_side determines whether portlet is on the right side or the left side of the portal page. sort_key determines vertical position of the portlet relative to other portlets on the page.
Portal data feed is a piece of tcl or adp code that generates content to be served inside the portlet. This code connects to internal or external database, retrieves the data, and returns the information the user is interested in.
create table portal_data_feeds (
data_feed_id integer
constraint portal_data_feeds_dfi_pk
primary key,
data_feed_name varchar(40)
constraint portal_data_feeds_dfn_un
unique,
-- predefined data feed can be tcl code, adp, or plain html
data_feed_type varchar(20)
constraint portal_data_feeds_dft_ck
check(data_feed_type in ('tcl', 'adp')),
-- this is used for display purposes. we want to know where to display the data feeds
data_feed_display_type varchar(20) default ('user-defined')
constraint portal_data_feeds_dfdt_ck
check(data_feed_display_type in ('predefined', 'user-defined')),
code clob
);
Data feed name is the unique name of the portal data feed. data_feed_type determines what kind of code is stored in the code column of portal_data_feeds. Possible values for data_feed_type are tcl and adp. data_feed_display_type tells us whether data feed is predefined or user-defined. Predefined data feeds are defined by developers and cannot be subsequently changed from web interface. User data feeds are created and modified though ACS administrator interface.
VIII Portal User Interface
Portal URL Specification
User Portals
|
| General Form |
Example |
| 1st page of the user portal |
/root_url |
http://xyz.com/home |
| nth page of the user portal |
/root_url/page-number |
http://xyz.com/home/page-2 |
| Control panel for portal |
/root_url/admin |
http://xyz.com/home/admin |
Group Portals
|
| General Form |
Example |
| 1st page of the group portal |
/root_url/short_name |
http://xyz.com/department/marketing |
| nth page of the group portal |
/root_url/short_name/page-number |
http://xyz.com/department/marketing/page-3 |
| Control panel for group portal |
/root_url/short_name/page-number |
http://xyz.com/department/marketing/admin |
Portal user interface
Portal pages of user and group portals look the same and share following features:
- Each portal page is a single html page consisting of four elements: header, footer, navigation bar and one or more portlets
- Portal page header of user portal displays the first and the last name of the user
- Portal page header of group portal displays the name of the group
- Footer contains email of the portal administrator.
- Navigation bar consists of links to portal pages other than the one currently selected
- Navigation bar includes a link to the control panel if one exists.
- Each portlet is a box with two parts: header and body. Header of the portlet displays the name of the portlet and optionally a link to the page where portlet's content is administered. Body of the portlet displays information generated by portlet's data feed.
- Portal user is not allowed to remove portlets that ACS administrator has designated as required portlets
Portal manager interface
(screenshot of portal page customization)
Portal customization page shown in the screenshot above is available at /portals/manage-portal. Using this interface, portal manager can easily customize content and layout of the portal.
Portal manager customizes portal content by specifying which portlets are displayed in the portal.
Portal manager customizes portal layout by specifying the number of portal pages, names of portal pages, by deciding which portlets go to each of portal pages, and by specifying vertical and horizontal position of portlets.
ACS administrator interface
ACS administrator interface all of the functionality specified by requirements document. Here is the list of functionality of every page in ACS administrator interface:
/admin/portals/index
- links to administration pages for all of the portal domains
- a link for creating a new portal domain
/admin/portals/domain-add
- adding a new portal domain
/admin/portals/domain-manage
- changing URL root of the portal domain
- removing portal domain
- reverting all portals in the portal domain to the default portal configuration
- a link for setting domain level display settings
- a link for setting default portal configuration for the domain
- a link for adding new portlet to the portal domain
- list of all portlets in the domain
- for each portlet there is a link for setting properties of that portlet
- for each portlet there is a link for removing that portlet from the portal domain
- for each portlet there is a toggle button for determining whether portlet is required or not
/admin/portals/portal-domain-properties
- setting domain level display properties
/portals/manage-portal
- setting default portal configuration for a portal domain
/admin/portals/portlet/create
- adding new portlet to the portal domain
/admin/portals/portlet/edit
- setting portlet properties
IX. Configuration/Parameters
Parameters file is used to set portal display settings. Here is an example parameter configuration for portals:
BodyTag=<body bgcolor=#FFFFFF text=black>
FontTag=<font face=arial,helvetica size=-1 color=black>
; These standardize a prettier table than the browser default
BeginTable=<table border=0 bgcolor=black cellpadding=1 cellspacing=0 width=100%>
InteriorTable=<table bgcolor=white border=0 cellspacing=0 cellpadding=2 width=10
0%>
EndTable=</table>
HeaderTD=<td bgcolor=#0033cc><font face=arial,helvetica size=-1 color=#ffcccc><b
>
HeaderBGColor=#0033cc
SubHeaderTD=<td bgcolor=#eeeecc><font face=arial,helvetica size=-1 color=black><
b>
SubHeaderBGColor=#ffffcc
TabHeaderTD=<td><font face=arial,helvetica size=-1><b>
TabSubHeaderTd=<td><font face=arial,helvetica size=-1 color=black><b>
NormalTD=<td colspan=2><font face=arial,helvetica size=-1 color=black>
; For portals with multiple pages, tabs link to the other pages, set this to 1 i
f you want each tab
; to be equal width instead of proportional to the name of the page
EqualWidthTabsP=0
; browsers will decide the "optimal" column sizes unless you force column widths
here:
;LeftSideWidth=30
;RightSideWidth=70
SpacerImage=/portals/pics/spacer.gif
In the future releases of portals, parameters file will go away and display settings will be set using cascaded style sheets.
X. Future Improvements/Areas of Likely Change
Infrastructure
-
Port to ACS4.0
Make portals work on multiple servers by replacing shared variable caching with the caching subsystem of ACS4.1
Architecture
-
Unique domain name in portal_domains table
-
Generic table parser. Instead of generating table html code on the fly, we should first generate table data structure of portal pages and then use adp skin to generate the html
-
Multiple portals per user or group
-
Portal domain can be defined for subgroups of a group. This will be very useful for sites making heavy use of subgroups, such as, Arsdigita's intranet.
-
Get rid of display settings in parameters file and use cascaded style sheets and/or adps to generate portal html
Functionality
-
Display settings can be changed for every portal (aka my.yahoo.com)
-
Remove portal button (aka my.yahoo.com)
-
Integration with YBOS's multicolumn, variable-width portal pages
-
Each domain can define it's own adp headers and footers
-
Portlets can be copied from one domain to another
-
Portlet based authorization. For each portlet, we want to specify what classes users have right to view it and administer it.
Security
-
adp code in portlet should be restricted only to
function calls specified by the developer. We don't want a person
with ACS administrator privileges to be able to execute arbitrary tcl
code from web interface.
XI. Authors
System creators
System owner
Documentation authors
Programmers
In addition, the following people made significant contributions to the portals package: Joe Banks, Scott Meeks.
XII Revision History
| Document Revision # |
Action Taken, Notes |
When? |
By Whom? |
| 0.1 |
Creation |
10/15/2000 |
Tarik Alatovic |
tarik@alatovic.com
Last modified: $Id: portals.html,v 1.2 2001/01/22 04:24:08 audrey Exp $
