This section covers the following topics:
A Site Studio application is an EAR file, containing multiple WAR files that deliver Site Studio web sites.
The examples in this section uses a Site Studio application called MyApplication with a web project called MySites. The structure of the EAR file is as follows:
+-- MyApplication.ear
+-- MySites.war
+-- adf/META-INF/
+-- connections.xml
+-- META-INF/
+-- application.xml
+-- weblogic-application.xml
MySites.war: This is the war file that references a single content server and delivers sites from that content server (see "JavaEE WAR File").
adf/META-INF/connections.xml: The ADF connections file that holds the definition of which content server is being queried at runtime.
META-INF/weblogic-application.xml: The Weblogic-specific application file that holds a reference to the Site Studio (and RIDC) shared EAR libraries.
Site Studio web sites are delivered via a WAR file. The Site Studio libraries can communicate with a single Oracle Content Server instance per WAR file. The structure of the WAR file is as follows:
+-- MySites.war
+-- wcm/templates/
+-- WEB-INF/
+-- web.xml
+-- wcm-config.xml
+-- weblogic.xml
wcm/templates: Directory containing all local templates (JSP/JSPX files) that are registered in the wcm-config.xml file.
WEB-INF/wcm-config.xml: The main Site Studio configuration file, which lists the available sites, connection name, and other configuration settings.
WEB-INF/weblogic.xml: Weblogic-specific file that holds the reference to the shared Site Studio WAR library.
WEB-INF/web.xml: The standard JavaEE configuration file that lists out the servlets, filters and security settings for the application.
Site Studio technology uses servlets, filters and tag libraries to deliver Site Studio sites via the deployed web application.
The examples in this section describe the default configuration for a single Site Studio site using the site ID MySite and is delivered via a Site Studio application called MyApplication:
These are the available Site Studio servlets:
SiteStudio Proxy Servlet: Proxies the content from Oracle Content Server to your local application; allows the content server to be treated as a local resource within the domain, allows for single sign-on via identity propagation.
Initialization Servlet: Initializes the Site Studio libraries; does not handle any web requests.
These are the available Site Studio filters:
Mode Filter: Handles the determination of the mode of the current request. The mode will either be Consumption, Contribution, or Design.
Site Filter: Delivers Site Studio web pages using the Site Studio URL syntax, based on the associated project file in Oracle Content Server.
Proxy Filter: Proxies the content server content to allow for the content server UI to be served from the local web application.
The mode filter listens for URLs which map to the contribution mode root (/wcm-contrib/*) or the design mode root (/wcm-design/*). If the first segment of the URL matches either of these URLs, the mode is set for the request and the resource is then forwarded, without the first segment, to the web application for processing.
The site filter allows for the processing of Site Studio URLs. Site Studio URLs are hierarchical, based on the structure of the a project file. A typical Site Studio URL looks like /mysite/about/index.html. For more information, see Section 1.6, "Understanding the Site URL Format."
Site Studio control flow:
Site URL via the browser is requested: /mysite/about/index.html
Determine the current site ID and section.
Matches against urlPath in the wcm-config.xml file.
The site ID is set to mysite and site path set to /about/index.html
Instantiate a new SiteContext object and place it in the HttpServletRequest as an attribute named wcmContext.
Determine the Page Template ID. In this case, page template is primary via the index.html file name.
Lookup the template ID in the wcm-config.xml file to find the local JSP/JSPX resource.
Invoke RequestDispatcher to include and render the associated JSP/JSPX page.
The proxy filter proxies the content server content, using the local user ID, to enable the Oracle Content Server user interface to be served from the local web application. This allows the web application to be integrated with Site Studio Contributor and the Oracle Content Server user interface pages, which reside in the content server domain.
This section provides notes on the various Site Studio technologies that can used to provide web content management functionality in external applications by integrating with other technologies and frameworks.
Site Studio technologies, including the Site Studio tag library, Site Studio helper methods and various Site Studio filters and servlets can be integrated with other technologies and frameworks, such as ADF components, to deliver web content management functionality to an existing application.
When using placeholder tags in externally managed pages or applications, the customer is entirely responsible for the validity of any links in the data file or generated by the region template. The conventional Site Studio section and content links are not relevant to an unmanaged site or application.
Context, Datafile, and Template tags are used in conjunction with Placeholder tags, and can be used in externally managed applications.
For more information, see Section 6.1, "Site Studio Tag Library."
Using Site Studio Helper Methods
Site Studio helper methods are available for scripting templates.
For more information, see Section 6.2, "Site Studio Helper Methods."
Integrating with Other Technologies or Frameworks
Site Studio tags can be added to other technologies (such as an ADF application or JSF page on a web site). When used in an integration, all URL management must be handled by the application or application server. Site Studio does not manage the application structure, perform the URL mapping, or the page templating.
Site Studio content can be combined with other components or task flows by adding either a static placeholder or dynamic placeholder to page or application.
A static placeholder is a placeholder with an explicitly assigned dDocName (content ID). In other words, the static placeholder is associated with the backing data file (and, optionally, region display template) at design time.
A dynamic placeholder is a placeholder that stores its backing data file dDocName (and, optionally, region template) in a project file. A dynamic placeholder is associated with a backing data file by business users using the switch region content functionality that is part of the contribution process. A context tag must to be included to define where in the project file the switch content action will write the values generated by the switch content wizard.