This chapter is from the book
This chapter is from the book
This chapter is from the book
The Database and Data Model
Because of the extensive use of XML documents, the database wouldn't be used in the centralized manner that was usually the case with Web applications. However, they would still use a database, mainly to store master permission information, including users and groups (this would be Project Omega's canned security app), but also to store the information for groups that would be accessing the portal.
Victor called this last group "affiliates." In the database, he would store the design information and the portlet registry that could be accessed by users in that group.
Victor created the ERD that could be used to develop the database (see
Figure I-3.2).
)
Figure I-3.2 Because of the use of XML registries and user preferences,
the database for the portal application stays fairly simple.
One item worthy of note and relevant to the overall data model was that once a user logged in, Victor felt it would be easiest to store that user's information—portlets, design and layout information, and other preferences—in a SESSION structure. He added this to the data model portion that would be included in the blueprint.
Part of the project would be to determine a basic layout and look and feel for the application. Ernie, who was working on overall design, put together a simple composite to reflect what the application would look like (see Figure I-3.3).
){kind=link}
In addition, Ernie listed some basic design guidelines, including a color palette and acceptable fonts to use. These could be approved by Sonic and then distributed to the developers to make sure that the design would be acceptable at the release of the project. Of course a good deal of the design would occur at runtime, depending on the group accessing the site and the design of the portlets. But having some basic guidelines at debut often helped in pleasing a client.