When you are developing an online site that is to be delivered from a WebCenter Sites content management system, you are actually designing two sites:
The online site that is delivered from your delivery system to visitors' browsers
The content management site(s) that your content providers will use to input the data that they will publish to the delivery system.
In other words, you are responsible for the user experience of two sets of end users:
The site visitors who use your delivery system
The content providers who use the management system
When creating these two closely connected yet separate sites, the development team performs a series of planning, development, and testing steps. This chapter describes the development process in one possible sequence of events and in very general terms. Your own work flow will vary based on your work environment and business needs.
This chapter contains the following sections:
The first step is to assemble the development team, which include the following kinds of people:
Site designers
XML and JSP developers
Java application developers
Database administrators
System network administrators
Marketers and advertising staff
Product managers (if you are developing a commerce site)
Content providers
You need people such as DBAs, system administrators, and content providers on your development team in addition to the people (like you) who do the actual coding for several reasons:
Using a WebCenter Sites system requires you to design a data model in addition to creating a page design, which means that you need early input from the DBAs who will be supporting the databases on each system.
Using a WebCenter Sites system means moving code and data around on multiple separate systems, several of which are probably clustered, which means you need early input from system and network administrators.
Implementing a WebCenter Sites system will not be optimum unless the work habits of your content providers are accurately reflected in the design of the management system, which means you need early input from those who will use the management system.
An online site delivered from a Oracle WebCenter Sites content management system is a holistic construct in which everything interacts, intersects, and works with everything else. Therefore, the second step is to create a functional specification and a design specification (to design your online site on paper).
You should complete some version of this step before you begin coding anything (although you might do some proof-of-concept coding while working on the design specification).
Before you can begin a design specification, product management and marketing must provide the functional requirements for the online site.
After you obtain the functional requirements from your marketing folks, a good place to start is to map out all the types of pages that you want to present on the online site. For example, home page, section page, columnist page, search page, article page, and so on. If you are designing a commerce site, you need other kinds of pages: registration page, product category pages, product description page, article page, FAQ page, invoice page, and so on.
Determine the graphical, navigational, and functional features for each page and the site overall: navigation bars, buy buttons and shopping carts, tell me more buttons, search functions, logo placement, animated graphics, and so on.
If you are using Engage, decide where the merchandising messages (recommendations) are to be placed on the pages and on which pages they'll be placed. For example, perhaps each product category page has a New Products section in the upper-right corner of the page.
Map out the entire structure of the site and create mock-ups of it.
One of the major elements in your design is caching: page caching and resultset caching. No online site can reach performance goals without your planning, testing, and implementing a caching strategy.
While designing the pages that you want to present on your online site, you must consider how and when page caching can and should be implemented for each piece on each page.
While designing your queries, you must map out all the tables in the database and determine how the resultset caching settings should be set for each table.
Will you require your visitors to identify themselves before they are allowed to access any part of your online site? You must determine what kinds of access control you want to enforce early in the design process so that you design your pages correctly.
For example, if you plan to check your visitors' identities before allowing them access to a page, this affects how you would cache the components of that page. For example, you could design a container page, which is never cached, that verifies the identity of the visitor and then assembles the page from cached pagelets only if the verification is successful.
Following the basic proposition of separating content from format, take a look at each piece of each proposed page in your site and determine whether that piece should be represented as data or as logic.
A good design is one in which data is designed to be represented as an asset and is not embedded into element code. Examine every component of design or content, and then determine what your assets are. You make that determination by deciding which category a component belongs to: data or logic/code.
Simply speaking, do not code something into an element (embed it in logic) if it is really data. If it is data, is should be in a separate asset.
Here's another way to look at it:
Assets that represent content are the responsibility of content providers.
Logic, anything coded into any element, is the responsibility of the developers.
Documents, articles, products, and images are easily identified as assets. However, design components such as headers and footers could also be assets:
When the content in a header or footer is embedded in the code of an element, you or another developer has to change the text in it when anything in it changes (a phone number, a logo, and so on).
When the content in a header or footer is in an asset, the code in your elements must be able to obtain the identity of the asset; its content becomes the responsibility of a content provider.
Other page components that can be assets include the following kinds of things:
Online polls
Animation and other media
Quote of the day
Company or stock profiles
Knowledgebase questions and answers
From your point of view, if the content for a component is represented in an asset, someone else is responsible for that content. You are only responsible for when and where it appears on your online sites and what it looks like when it appears there.
You have two general options when deciding how to manage the images and other blobs that you want to use in your online site:
Treat them as assets: Store them in the WebCenter Sites database and have the BlobServer servlet serve them.
Treat them as static files: Put them in a file structure on your web server and let the web server serve them.
Either method is a valid option. If you keep your image files on the web server, you can create links to them with the WebCenter Sites tags, and there may be performance benefits when you allow your web server to deliver your images. However, if you keep your images and blobs separate from the WebCenter Sites database:
You must implement a separate file management process. The publishing methods that move image assets from your management system to your delivery system cannot move content that is not in the WebCenter Sites database. You must manage this process on your own.
None of the native WebCenter Sites security mechanisms will apply. That is, you cannot use ACLs to limit access to blobs that are not managed by WebCenter Sites.
You also need to analyze all of the functionality that you plan to incorporate into your online site. If you are designing a commerce site, parts of it will no doubt behave more like an application.
Outline what code or logic is required for your visitor registration pages, visitor data collection pages, shopping carts, personalization, and so on.
Remember that your WebCenter Sites system provides you with coding options: Java, XML, and JSP. As you look at each of the functions you want to provide, determine which is the best coding solution for that function.
Once you know which pieces of your site should be represented as assets, you can map out what your asset types should be. Each new asset type will use one or more database tables (depending on whether it is a basic or flex asset type).
No matter which asset model you are using, basic or flex, consider the following when you design your asset types:
Asset type design affects both of the user groups that you are designing for (visitors to the online site and the content providers who must enter the data).
Which types of assets need to be linked or related to other assets of other types in order to successfully implement your page design? Be sure to implement these relationships in the asset type.
Content providers appreciate efficiency. Be sure that your asset types store only the data that you really plan to use so that content providers do not waste time maintaining data that no one uses.
The data design that you want to implement for your system extends beyond the database tables that hold your assets. Depending on the kinds of information that you want to provide, you might need to create auxiliary tables that support your asset types.
For example, the Burlington Financial sample site has asset types with a Mimetype field. The Mimetype field is a drop-down field and a user must select a value from the drop-down list. These values are pulled from a lookup table named MimeType. Depending on your needs, you might need to create similar tables for your system.
Your DBAs should be involved in your discussions about the asset types and auxiliary tables that you plan to create so they can understand from the start the kind of database tuning issues that might arise on the management and delivery systems.
If you are using Engage, you also need to determine what kinds of visitor data you plan to gather. These data types are represented by the Engage visitor data assets that you use to create segments for personalizing your site based on the identity of the visitor. (For example, demographics, purchase history, or clickstream information.)
After your WebCenter Sites system goes live and you start collecting visitor data, the tables that store that data grow very quickly. This is another area that you need to consult your DBAs about.
Before you can begin coding, you must know how the management system will be organized. These decisions affect your design because your design depends on the content management site.
A content management site is an object that you use as an organizational construct for an actual online site and as an access control tool. When you create Template assets, WebCenter Sites creates an entry in the SiteCatalog table for it. The naming convention that WebCenter Sites uses for the page entries for templates includes the name of the content management site that you are creating the template for. This means that you must be consistent with site names throughout your entire content management system (development system, management system, and delivery system) and you must know the names of the sites that you are using before you begin coding.
Although your primary concern is the name of each site, the system administrators and business managers must also determine the following:
How many users and ACLs (access control lists) do you need? (Remember that you may need to create ACLs to assign to the visitors of the online site, as well.)
How many site roles you do you need?
Which asset types need a workflow process?
Which asset types should use revision tracking?
Who should have access to which asset types on which sites?
Use both this book and the Oracle Fusion Middleware WebCenter Sites Administrator's Guide to help you make these decisions.
After you have created your design specification and you understand the organization of the management system, you can implement the data design.
On the development system, you complete the following kinds of tasks:
Create content management sites with the same names as those that will be used on the management system.
Design and create your asset types.
Add any lookup tables or other auxiliary tables for the asset types.
Create sample assets of each type.
This step and the next step (Section 3.5, "Step 5: Build the Online Site") are iterative and will most likely overlap a great deal. While you need to create asset types so that you can create assets before you create templates for them, it is likely that you will uncover areas that need refinement in your data design only after you have coded a template and tested the code.
Refer to Chapter 11, "Data Design: The Asset Models" when you implement the data design of your online site.
After you have sample assets of even one type created on the development system, you can begin coding templates and building the online site. (Actually, you can begin coding elements that do not display assets any time after you have created your design specification.)
In this step, you complete the following kinds of tasks:
Create the page, query, and collection assets that implement the functionality of your online site.
If you are using Engage, create the visitor data assets, sample segments, recommendations, and sample promotions.
Create Template assets (and code template elements) for all of your asset types.
If content contributors are using the Web Mode feature of the Contributor interface, code the templates using the insite family of tags.
Code the CSElements that implement underlying functionality (that do not display assets).
If you are developing a commerce site, code pages that implement the shopping cart.
If you are using Engage, code pages that collect visitor data.
Test everything. Most likely you will perform both usability and market testing for your online site.
Refer to Chapter 4, "Programming with Oracle WebCenter Sites" as you build your online site.
After you have the online site working on your development system, you move it to the management system.
The developers complete the following kinds of tasks:
Create the sites.
Re-create the asset types.
Mirror the asset type tables and auxiliary table from the development system to the management system.
Mirror publish the site design assets and the data structure assets created on the development system to the management system.
The system administrators then complete the following kinds of tasks:
Create users, ACLs, and roles. Assign users their roles for each content management site.
Configure Sites Desktop users, if you are using that feature.
Create workflow processes.
Create StartMenu shortcuts.
Enable revision tracking.
Refer to the Oracle Fusion Middleware WebCenter Sites Administrator's Guide for information about setting up the management system.
It is likely that you already have content in some non-asset format that you want to use. To import this content into the WebCenter Sites database as assets, use the XMLPost utility.
If you are using the flex asset model and you have a large amount of pre-existing data that you want to use, you can import it with the BulkLoader utility. For systematic updates, however, you use the XMLPost utility.
Before the editorial team can successfully maintain the online site, they need to understand your design. For example, how frequently are collections supposed to be rebuilt?
If you are using the basic asset model, content providers need to know the following:
Which categories and sources they should assign to their assets in order for their assets to be located by the appropriate queries and collections.
Which templates they should assign to which assets.
Which association fields must be filled out in order for the links on the site pages to function correctly.
It is a good idea to program as much of this information as possible into the Start Menu shortcuts that you and the system administrators create for each asset type.
If you are using the flex asset model, content providers need to know the following:
The general hierarchy or taxonomy in place for the flex assets.
Some information about what information a flex asset inherits.
Which templates they should assign to which assets.
When you set up the delivery system, you complete several of the same steps that you complete for the management system. For example:
Re-create the sites.
Re-create the asset types (but without their Start Menu shortcuts).
Mirror the asset type tables and auxiliary table from the development system to the management system.
And then you publish all of the assets on the management system to the delivery system.
Also, because this system is not a management system, you complete the following steps as well:
Implement your security strategy.
On the web server, map the URL of your site (www.example.com) to the WebCenter Sites URL of your home page.
For information about setting up the delivery system, see the section on publishing in the Oracle Fusion Middleware WebCenter Sites Administrator's Guide.