| Oracle® Fusion Middleware Developer's Guide for Site Studio for External Applications 11g Release 1 (11.1.1) E13650-01 |
|
 Previous |
 Next |
| Oracle® Fusion Middleware Developer's Guide for Site Studio for External Applications 11g Release 1 (11.1.1) E13650-01 |
|
Previous |
Next |
Planning is key to building a successful Web site with Site Studio. Before you begin inserting text, graphics, and scripts into your page templates, you should ask “What is the function or role of the site?” Is it a department-level site, a company-wide site, an internal site, an external site? How many users will visit the site? How many users will contribute to the site? Will there be different security access levels for each contributor? Do you plan to replicate or publish the site? Is the site expected to grow over time?
These are all important questions to ask before you begin. We cannot predict your particular needs, but we can suggest some key points that you should consider before developing your site:
Proper planning of the Web site helps determine how to maximize reusability of the Web site through appropriate use and reuse of page templates, subtemplates, and region templates.
It is important to understand that the more time spent on the planning process, the easier the Web site and the site assets are to create and manage. You might think that there is more time required to plan a managed Web site using Site Studio, but the result is much less time spent managing the assets.
Proper planning is vital to making the site easier to run. In the beginning stages, it might seem as if more time is being spent before any pages are complete compared to older methods of creating a Web site. But the results of time spent properly planning the Web site makes the construction of it through the site assets much easier, and the maintenance of the Web site, especially when making later changes when the Web site is live.
What Parts of the Site Will Be Reused?
When you consider the Web site, you should look at all content and all of the structure and consider what is reusable, and what should be used only once. When considering this, it could be thinking of simply the layout of the page, or it could be simply what data is displayed, or it could be a consideration of a certain piece of data displaying in a certain way.
Because there are so many ways of arranging and reusing the different parts of the site, it may be helpful to look at these examples of organization and reuse to think about while you consider your own Web site.
In a typical Web site, there is the navigation on the left, the banner graphic on top, and a large central area with the information on the page itself. We would expect that the banner and the navigation should be on all pages, so this would be placed on the page template itself. But the information in the middle will obviously be different from page to page. This is where the considerations are most important.
The way the information is organized is the most important consideration. When you look at one page, it may have objects arranged in one column, or in an array, or broken up with images. It's possible to arrange everything in one placeholder, but there is the other aspect, where you can create smaller sections, each with its own smaller contributor data file.
Consider a page on your Web site that would list open employment positions. You could create the page such that it is one placeholder, listing all internal positions and all external positions. Or you could create a subtemplate within that placeholder (which would then contain separate placeholders and region templates, and so forth), so that the external positions would be stored separately from the internal positions. Each could be maintained in a separate contributor data file, so that the external Web site would contain only the external announcements, and the internal Web site would contain both the contributor data file with external announcements and the one with internal announcements.
Another use would be where each department in the company could list their own job openings; then, on one central page, you could collect all of those individual openings and display them all. In these instances, you can use a subtemplate to easily manage the differing numbers of placeholders.
Other considerations for how you lay the data out on the page, and how to organize the placement of the data within the Web site, needs this kind of consideration on a page by page basis.
You should consider these questions: Would it be best to use one placeholder on the page template, then use a subtemplate to break that placeholder up into parts? Or would it be better to have a few more page templates to allow for different placeholder arrangements?
Another example would be an instance where you have a small piece of information that does not necessarily need a separate page, but you would definitely want to reuse. An example of this could be stockholder contact information, or possibly job application information, separate from typical corporate contact information. The information is not enough to necessarily warrant its own page.
In all of these cases, the page template would be the same. It would have the banner, the navigation, a footer, and then in the middle, the placeholder representing the area that can be replaced and filled with any information you need, structured exactly as you need it. It was the consideration of how to use a subtemplate to further use a placeholder or multiple placeholders within that template that enables you to keep the single look that you need for all pages.
It would also be possible to achieve this layout with different page templates on each page. Again, it depends on how you plan your site.
As you can see, the most important part of the site creation is to figure out how each portion of the Web site, both in terms of structure and content, is displayed. With Site Studio, the more time you invest in planning before you create, the less time you spend creating the hundreds and even thousands of pages your Web site delivers.
The site hierarchy is the framework of your Web site. You should give yourself plenty of time to plan the hierarchy before you start creating web pages. The site hierarchy not only helps you organize and manage content on your site, but it is also used by Site Studio to automate certain tasks.
How Deep Should the Hierarchy Be?
A deep hierarchy places information at multiple levels where information is heavily categorized. This works well for large organizations or any organization that anticipates growth on the Web site.
When planning the Web site, a lot of care should be taken in considering the hierarchy of the web pages within the site. The Web site hierarchy can be as deep as you want, and as deep as you want. You can create as many different sections from the home page as needed, and a section can contain as many sections as needed as well. However, the thing that should be kept in mind while designing the hierarchy is that while the structure can be as wide as needed (that is, sections can be nested to any depth), that this can create unwieldy URLs. The wider a section is nested in a Web site, then the longer the URL is to retrieve that information. Usually this is a trivial consideration, but for some designers this can be a major point.
Each section listed in the site hierarchy can have a primary page, and a secondary page. Since secondary pages are the pages that have replaceable content, the secondary pages are used to create multiple versions of the pages within a section. The primary page within a section is the page that opens for that section, it could be considered the landing page for that section.
How Will The User Navigate the Site?
While you use your site hierarchy to manage your site, visitors use your hierarchy to browse to and locate content. In Site Studio, when you add a navigation fragment to a page template, the fragment reads your site hierarchy and generates links that comprise the overall site navigation. You can easily add, remove, and rename sections of your site, and these changes are seen in your site navigation. You should think carefully about the visitor's experience as you construct this hierarchy.
How Should the Sections Be Named?
Your site hierarchy has individual sections with names such as Products, Services, and About Us. These names are important. They not only help you organize content on your site, but they display in the navigation on the site, where visitors see it. It is a good idea to revisit these names regularly to ensure that they reflect the content of the sections they represent.
Another thing to consider as you assemble your site hierarchy is the Web site address that contributors and site visitors see in their web browser address bar. By default, Site Studio uses the names (labels) that you give to the sections in your site hierarchy.
You can override these values, if you like, by specifying a different path name and page name for each section. It is best to plan this ahead of time to minimize any late changes to the site address or paths used in the address, which could result in broken links or missing shortcuts for contributors and site visitors.
How Reusable Should The Page Templates Be?
As you plan your site, you can create new page templates for each section, or you can reuse page templates that are already being used in other sections. When you design to use a small number of page templates, you then have fewer assets to manage, which makes the entire Web site easier to manage.
By reusing page templates, you can maintain the look and feel of your Web site in one or just a handful of page templates, and the changes are seen immediately across the site.
By creating new and unique page templates in each section, you might have more flexibility in the design of the site layout as a whole. You can create a unique design or slightly modify a different page template to accommodate the content that display there. However, if you make significant global changes to the site, then you have to modify multiple page templates. This might become a repetitive task that lends itself to mistakes and inconsistency.
If you choose multiple page templates, you should try to reuse fragments with referenced snippets as much as possible so that you can make global changes to just one or a handful of fragments.
However, through thoughtful use of subtemplates with the placeholders, it is typically possible to reduce the number of page templates.
Should There Be Both Primary and Secondary Pages?
There are several ways to handle page templates. You can assign one primary page and one secondary page for every section of your site hierarchy.
The primary page is the web page that users see when they go to that section on the Web site (similar to the default page on a conventional Web site). The information on the page is statically linked. Contributors can change the contributor data file or the native document on the primary page, or the information in the data file through the contributor interface.
The secondary page is a page that can have its content dynamically placed. A secondary page can have static content, but what makes secondary pages useful is their ability to have dynamically-placed content.
You can create a site comprised entirely of primary pages, but then you'll have to create new sections with new primary pages in order for the site to grow. By using secondary pages, your site can grow on its own from additional content submitted by contributors, and you, the designer, do not have to do anything. Your site becomes much more scalable with secondary pages.
Primary and secondary pages can have the same page template. The page template is not related to whether the page using the template is primary or secondary.
How Will Content Be Reused?
You can share and reuse contributor data files and native documents across a single Web site and even multiple Web sites in the content server. When you add these items to your site, you specify a specific location, or multiple locations by reusing associated site assets, where you would like them to appear.
You can even add content to your site that is not currently associated with any Web site in the content server. You can show the same document on different sites, each with its own look and feel, without having to create multiple versions of that same document.
If you choose to do this, however, you must ensure that the content is appropriate for the Web site and for public viewing. Workflows are good to implement to ensure this. You also must ensure that you have a secondary page with a replaceable region template in each section where the content appears.
Will A Manager Be Necessary?
You can create and manage the site hierarchy yourself, or you can hand this responsibility over to a site manager. The site manager can create sections, modify sections, and more.
These changes can significantly change the appearance and behavior of the site. You should think about these changes and how they affect the structure of the site, workflow, replication, the role of contributors, and much more.
As you plan the site hierarchy and prepare the assets for the Web site, you must think about your contribution model. That is, how content gets placed on the site by users (contributors and managers).
How Much of the Site Will be Provided by the User?
There are some things that the designer must add to the site, such as the background color, positioning devices (HTML tables or CSS), site navigation, and custom scripts. But much of the content for each web page (that is, the actual information on the page) can be created and edited by a contributor.
To really harness the power of Site Studio, you should open up as much of the Web site as possible to these users. This way, your Web site can be continuously updated without the bottlenecks or delays typically associated with a Web site.
How Much Control Will the User Have?
On every page template, you can have one large contribution region or several small contribution regions. Within a region template, you can have one or several elements, each one appearing as a field where users (contributors) add and edit content.
There are different types of elements that can be used for specific purposes, like adding and editing text, graphics, and updating lists. You can turn on or off certain formatting attributes, such as the choice of typeface, font size, images, tables, and custom properties. These choices depend on how much control you want the contributor to have over a given web page. You can also enforce what content is added using the validation feature or your own validation scripts.
Will There Be Different Security Access for Each User?
You should know your users, their role in the organization, and their knowledge of web publishing before you give them access to the site. You may want to provide equal access to all contribution regions on the Web site for all users, or you may want to limit access for some and grant full access to others.
For example, you may want to provide full access to the entire web page for members of the marketing department and access to only a portion of that page to all other departments. To do this, you would set up different users on the content server, assign a different contributor data file or native document to each region, and assign unique security metadata (using the metadata framework on the content server) to those files.
As a result, only the files that a particular contributor has permission to edit will display a contribution graphic (Figure 3-1) on them on the web page when in contribution mode.
Sections of the Web site can also be marked so that only certain users can view them. This is handled in the section settings within the Web site hierarchy. After the section has limited access, the section is available for viewing (and editing, if you want) to only those users that you want to have access.
Will Contributors Submit Native Documents?
In addition to adding and editing content stored in Site Studio data files, contributors can also add native documents (created from applications like Microsoft Word, Excel, or PowerPoint) to the site. These documents can be converted into web-viewable renditions using dynamic converter component on the content server.
Contributors can add new and existing native documents directly to the Web site (for example, by assigning one to a region, using the link wizard, or adding one to a dynamic list).
If you allow contributors to submit native documents to the Web site (and again, you control this in a contribution region, an element, and a list fragment), you should educate them on how they should use the native document and any style guidelines you may be enforcing.
How Will the Contribution Process Be Coordinated?
If you are the designer, manager, and contributor of your Web site, you know when and where the site must be updated. If, as the designer, you are working with a single contributor or manager, you must communicate the required updates for the site. Specifically, you should inform them of certain changes to the site. The contributor, however, may also alert you when content has been added.
If you are working with multiple users, communication can quickly become complex. You must include some kind of communication process between users. One solution is to introduce a formal review process using workflows. This means that various persons review and approve site changes before they become live.
Site assets in Site Studio are intended to be reused. Since the asset itself can be used in not only different areas of a Web site, but also in different Web sites that you are designing, the naming of each asset is important. With a good naming scheme, assets can be more easily managed and more easily deployed in one or many areas of a Web site, and one or many Web sites.
The best way to name an asset is to describe what it does and how it functions, rather than by using a name based on where an asset is used in a Web site.
The first thought of many designers is to put the name of the Web site in the name of each asset. This would group them when listing the contents of the content server. But the difficulty here is when you run multiple Web sites, since all of the assets are reusable. Rather than create an entirely new set of assets and definitions for a certain section in your Web site, you can easily import the other assets you've already created. In doing so, though, when the assets have the name of the other Web site in the name, this can cause some issues of continuity, understanding, and even some confusion regarding why some assets are present.
Names of the assets should also avoid the place of the asset within the Web site as you may run into some issues when reusing assets. For example, by naming a page template originally intended to be the primary page template as primary_template, there may be some confusion when that same template also ends up being used on the secondary pages. Proper planning would have eliminated this issue, giving the template a name such as page_template_with_2_placeholders.
Consider these two different methods of naming the site assets in your project:
| Naming convention with little planning toward maintenance: | Naming convention with considered planning toward maintenance |
|---|---|
| placeholder_def_1
p_def_2 default_definition front_page_template subtemplate_up element_title region_replace |
element_def_WYSIWYG_fulledit
element_def_imageonly_minedit placeholderdef_subtemplate_newslist regiondef_customform regiontemplate_title_and_body pagetemplate_home pagetemplate_errorhandler |
Future updates are much easier to handle when the assets are named to describe what they do, allowing you to place them as needed. This also means you do not have to look in all managed Web sites for an asset that you have already created.
After the Web site has been planned, the assets used to construct the Web site should be created. For the most efficient use, it is recommended that you create these assets in a particular order.
The most efficient method of asset creation for most Web sites is to build the assets from the bottom up, starting with your element definitions.
It is not required that you create the assets in this order. However, your Web site can be quickly and efficiently assembled if you follow this order.
The most efficient assets to define first are the elements. Elements are the assets that define the editing interface that the contributor uses. The specific use of each one is handled through element definitions. By creating an element definition, you are defining how the contributors work with the data files by defining the editing regions and the toolbars accessible to the contributors.
In the element definition you can control exactly which editing features are available to the contributor in the toolbar. For instance, you might not want the contributor to be able to change the font size or color, but still be able to use bold and italics. Generally you define at least one of each kind of element (WYSIWYG, text only, image only, static list, dynamic list, and custom) and usually, you define two or more of each type of element to allow for the different toolbars in Contributor.
The element definition is used to control the toolbar that the contributors can access to edit the pages. However, it might be that you want to have several different definitions for each element so that you can have multiple options of toolbars for the contributors, rather than one or two. It is important to consider the role of the contributor and how much they contribute on different pages.
It is highly recommended that you name the element definitions carefully, as naming the elements with respect to place on the page or with the name of the site in them can make reusing them less intuitive. It is not recommended that you name the element in terms of its place on the page, within the Web site, or even by using the name in the Web site within the element definition. The optimal method for naming an element definition is to list a relative amount of access in the toolbar, such as element_WYSIWYG_fulledit or element_text_undo_only.
Notice that the element definitions were named starting with the word element. That is to make all elements appear together when searching for them in the content server. Using other naming conventions such as including the name of the Web site would also group the assets in the web server, but this would make the definitions less intuitive to manage if you use the same definitions for multiple Web sites.
You should create region definitions before you create region templates. A definition (region definition, placeholder definition, element definition) controls which data is displayed and how the contributor interacts with the data. The template (region template, subtemplate) control how the data is displayed. The region definition, specifically, controls which elements (WYSIWYG, Image only, and so forth) open in Contributor. The region template is used to arrange the placement of the elements and how that particular data is displayed on the web page.
As you create a region template, you are asked to associate it with a region definition. If the definition is not already defined, the region template is not easily associated with the definition afterward.
The typical region definition contains multiple elements, and various combinations of these elements are used on several different region templates. That is, the region definitions are as broad and encompassing as possible. This allows multiple region templates to access the same grouping of elements (but it does not have to be the same data file) and arranging them in different ways.
Because the region definitions limit the availability of elements in the contribution model, it is especially important to follow good naming conventions for region definitions. This helps you sort out which definitions are best suited for the different region templates you create.
Region templates are the assets that format the data files into HTML. You use region templates to place the content, such as text, images, or other simple items, that would not be inside of an element, and the elements. The region templates are used to arrange the elements (limited by the region definition) into the layout desired to be reused as you see fit in the different places in your Web site.
The region template has available to it only those elements that have element definitions listed in the region definition for the template. However, the region template does not have to use all elements listed in the definition. This allows for a great deal of variety in the different templates available.
It is likely that region templates are the largest number of assets you create for the Web site. Because of this, the naming convention you use in creating the region templates is important. The name should help define what the template does, not where on the page it is used or where in the Web site. A name such as regtem_titlebodyview or rt_bodynoimage would likely be a more useful name when maintaining the site than would, say regiontemplate14 or RT_SupportForum.
Since region templates can contain HTML and images and other assets (for example, a region template-specific CSS) that are not part of the data file that is passed through the elements, the templates can be used to incorporate some information and text that is not editable by the contributor. However, it is important to understand that any of that information is not part of the contributor data file that the contributor edits. This means that as you reuse a region template, the data associated with it displays in the same manner regardless of what data is associated with that region template. It also means that the designer is the only person who would be able to modify that particular data. The contributor would be able to create and edit any data that is assigned to the elements in the region template through the placeholder, but anything that is placed outside of the elements, but still within the region template, would be static.
Subtemplates are major portions of HTML that can contain placeholders. This makes them very useful as a way to reduce several page templates while still maintaining several different ways the pages in the Web site can appear.
Subtemplates can only appear in a placeholder. Subtemplates can only contain a placeholder, or static content such as HTML or an image. A subtemplate can also reference a CSS file.
Is a Subtemplate Necessary for the Site?
One of the benefits of using a subtemplate is that you can reduce the number of page templates used in a Web site. Through a subtemplate, you can have the same page template used for both primary and secondary pages.
This is one reason why planning is essential. While a subtemplate can reduce the number of page templates, it also means that you have a subtemplate to manage for the Web site. Fewer page templates means that site-wide changes are easier to make. Subtemplates can also add a level of static information because you can add HTML, images, and other similar static site assets to a page that you may want placed on a certain number of pages (such as the secondary pages) that would otherwise have to be managed separately from the subtemplate.
The subtemplate can also help you place multiple placeholders within a single placeholder. Since a placeholder can contain a subtemplate, and a subtemplate can contain a placeholders, then it could be that you want the subtemplate present for future Web site expansion that is still to be determined.
Placeholder definitions are what connect each placeholder to the content and other assets associated with that placeholder to display.
How Will The Placeholder Function On The Page?
The placeholder, not to be confused with the placeholder definition, is simply a mark on the page in the application to identify where there is a contribution region (that is, editable area) on the web page. Placeholders are simply conceptual boundaries. The actual amount of space that a placeholder uses on a web page is determined by the size of the content placed in it.
The data associated with the placeholder depends on which page the placeholder is on, which happens after the site structure is complete and you begin to place content in the sections of the Web site.
It is the placeholder definition that determines how the placeholder functions, and what the placeholder contains. This means that you should view the placeholder as an available section for you to use and reuse content in broad areas. It is common to have a page template, for instance, with only the navigation and the header image and nothing but a placeholder in between. This placeholder would then be easily replaced on any number of pages with the content specific to those pages. The content can be broken down into smaller placeholders if your design planning has led you to create a site based on a minimal number of page templates and using multiple placeholders and subtemplates in different ways.
What Will The Placeholder Definition Control?
The placeholder is little more than a tag that is meant to define an area on the page where the content is shown. The placeholder definition lists which region definitions (and their associated region templates) and which subtemplates are available to pass information through.
You can also control other details on a placeholder-by-placeholder basis through the placeholder definition. Some of these items include workflow, whether the contributor can edit the data displayed through the placeholder, whether the contributor can edit the metadata, ability to view Web site usage reports, and the ability to view content tracker reports.
A large number of Web sites can be reduced to two simple page templates: the home page, and then all other pages. It is not uncommon for a Web site to have a home page that is distinct in terms of layout and design compared to the other pages in the Web site.
It may be the case that there are multiple templates for your site. It is also possible to make an entire Web site work with one page template. If you do design the Web site with several page templates, you should possibly consider the use of subtemplates to reduce the number of page templates. Fewer page templates on a Web site makes site-wide changes much easier.
Will Primary and Secondary Pages Require Different Templates?
Primary and secondary pages can both use the same page templates. However, since secondary pages are the only pages that can have dynamically placed content, you should consider the effect on how you view your page templates (and even your placeholders and placeholder definitions) with respect to the advantages of dynamically placed content.
A secondary page serves as the backdrop for content added to the site by a contributor. Secondary pages are required if you allow contributors to add contributor data files or native documents (both of which amount to new web pages) to the Web site. These files are made available to the site when they are picked up by a dynamic list, a search, or the target of a link.
It may be that you first build your site with just primary pages, saving secondary pages until after you set up contribution regions on the primary pages and know exactly what type of content contributors submit to the site. Then, you could add the secondary pages to handle this content.
Regardless of whether you use the same or different page templates for the primary and secondary pages in your Web site, it is important that you name the page templates appropriately. This is the same for all other site assets in Site Studio. Say, a page template is used for both the primary and secondary pages. If the name of that page template was based on where it was initially placed in the site, the template name could lead to confusion when the site is expanded and the page template is being reused for secondary pages as well.
The most efficient naming of site assets, including page templates, should be based on how the page template is used. Naming conventions based on where the asset is used in a Web site (for instance, page_template_primarypage) or based on in the order of creation (for instance, pagetemplate3) can make the assets harder to manage.
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
