Site Studio for External Applications is a powerful, flexible web development tool that offers a comprehensive approach to designing, building, and maintaining enterprise-scale Web sites in an Application Server environment. Web site development and template creation is performed in the JDeveloper environment. Site assets, such as files and graphics, are stored and managed in the content server. Page templates, region templates, and subtemplates (which are typically JSP or JSPX pages) are located in the WAR file of the web application associated with your JDeveloper project.
Site Studio for External Applications dramatically improves productivity and allows organizations to maintain accurate, timely, and current web content with consistent branding and presentation across all corporate sites. With Site Studio, you can centralize control of site architecture and presentation, while distributing content development and ongoing maintenance to business units or other teams. Additionally, Site Studio for External Applications can be integrated with third-party applications servers.
This section covers the following topics:
This is the basic structure of a Site Studio project:
+ Site Files
+ templates
+ page
+ region
+ subtemplates
+ Web Content
+ wcm
+ WEB-INF
+ sites
- wcm-config.xml
- web.xml
- weblogic.xml
Please note the following nodes and files:
Site Files: This is a virtual node that points to the Web Content/wcm node.
Web Content/wcm: This node contains the page templates, region templates, and subtemplates for this project.
Web Content/WEB-INF: This node contains the XML descriptor files and configuration files.
WEB-INF/sites: This node contains the XML files that store the data and configuration information for the Site Studio site. See "Understanding Site Studio Site Files" for more information.
WEB-INF/weblogic.xml: The Oracle WebLogic deployment descriptor file.
In JDeveloper, Site Studio site files are located in the sites directory of your Site Studio project (from the main menu, select View then Application Navigator then Projects then expand Web Content then expand WEB_INF then sites). Site Studio site files are XML files that store the data and configuration information for the Site Studio site. The XML file is maintained on JDeveloper, but all content resides on the content server.
The site files contain site-related information including:
The site hierarchy.
Properties of each site section (including associated page templates, region templates, and content files, and custom section properties).
Explicit data file associations (for example, which content files are used and their location in the site).
Mappings of placeholder names to placeholder definitions.
Items in the asset pane (including how they are categorized).
The site URLs are hierarchical, allowing navigation through a given project file. They have the following general format:
/[Site Identifier]/[Section 1]/[Section 2]/.../[content].html
Site Identifier: The path that identifies a site, the URL pattern listed in the wcm-config.xml file.
Section: A list of sections, identified by the either the urlDirName attribute or the label attribute in the project file.
Content: Can be the content ID (dDocName) of an item on Oracle Content Server, or index to refer to the primary page.
For example, a path to the primary page of the About section:
/mysite/About/index.html
A path to a piece of content to display in the Products section:
/mysite/Products/new_product.html
Templates (page templates, region templates, and subtemplates) in Site Studio are typically JSP or JSPX pages. The templates are located in the WAR file of the Web application, typically as a subdirectory of the /wcm/templates directory. Any template type can contain any valid JSP syntax. However, it is assumed that the templates will have the following structure:
Region Template: For modeling data file content. Typically contains either a wcm:dataFile tag or wcm:dynamicConversion tag to retrieve the assigned content. It does not contain wcm:placeholder tags.
Subtemplate: Like a page template, but is typically responsible for a portion of a page after being assigned to a placeholder. May contain other wcm:placeholder tags.
Templates are registered with a unique identifier in the wcm-config.xml file. This identifier is used to identify the template throughout the Site Studio application. The identifiers are used in the project file to identify page templates (either primary or secondary) and are used in placeholder definitions, to identify a region template or subtemplate.
This template maps the name homepage to the path /wcm/templates/page/homepage.jspx. When the homepage identifier is encountered, the RequestDispatcher is invoked to include the path.
<mappings>
<pageTemplates>
<mapping path="/wcm/templates/page/homepage.jspx" id="homepage"/>
</pageTemplates>
</mappings>
There is no requirement that the template has to point to a JSP or JSPX file. The mapping can point to any valid web application resource. For example, a section could point to another servlet for processing:
<mappings>
<pageTemplates>
<mapping path="/servlets/reserveMeetingRoom.do" id="reserveMeeting"/>
</pageTemplates>
</mappings>
Communication with the content server is through the IntradocPort, typically port 4444 on the content server. This allows Site Studio to assume the role of any user. All placeholder content is therefore retrieved as the user specified in the wcm-config.xml file, on the contentServer element as the adminUser. Subsequently, all content displayed in a placeholder (data files, native documents, etc.) and all content retrieved through the proxy servlet perform a security check for read access.
In the wcm-config.xml file, the security element defines how security is handled. If the enabled attribute is set to false, no security checks are performed in consumption mode and all content displayed through the placeholder will be readable. Requests through the proxy servlet will still be validated.
Depending on your content server configuration, you can also specify the level of security using the securityType attribute (each level is in addition to the previous level):
Contribution & Design Mode Authentication
Contribution and design modes require authentication to the application server running the site. This is done using the security settings in the web.xml file:
<security-constraint>
<web-resource-collection>
<web-resource-name>ContributionMode</web-resource-name>
<url-pattern>/wcm-contrib/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>WCMContributor</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>OpenWCM</realm-name>
<form-login-config>
<form-login-page>/wcm/support/login/wcm-login.jsp</form-login-page>
<form-error-page>/wcm/support/login/wcm-login.jsp</form-error-page>
</form-login-config>
</login-config>
<security-role>
<role-name>WCMContributor</role-name>
</security-role>
Upon selecting Ctrl+Shift+F5 on a page with placeholder content, the page is refreshed to a URL with /wcm-contrib as the first segment. The application server then validates that the user has the appropriate application role assigned to them via the application server. The role name, as described in the web.xml, is WCMContributor. If the user does not have this role, a login screen is presented and the application server denies access until the credentials are validated and the role condition is met.
The default login page can be customized by changing the web.xml to point at a customized JAAS login page or by adding a local copy of the file /wcm/support/login/wcm-login.jsp to your web application. This page will then be used instead of the shared default version.
Once in contribution mode or design mode, the user ID is now used to validate security and all placeholder content is retrieved live from the content server. Additionally, the rendition is switched from Latest Released to Latest so the contributor user can view content in workflow or otherwise not yet released.
Content is cached in a temporary location on the application server. This can be customized to a particular location using the stagingDir attribute on the staging element in the wcm-config.xml file. The content cache stores a local copy of all files, associated metadata, and any associated conversions or renditions.
Any request for content first checks the local cache. If not found, the content server is contacted and the content is placed into the cache. Note that no security information is cached; all security calls go to the content server. Additionally, only Latest Released content is cached; content retrieved during contributor or design modes (Latest Rendition) is not put into the cache.
A background thread, controlled by the contentServer element using the pollerInterval attribute, pings the content server at regular intervals to keep the cache content up to date. A content server administrator can, using cache information, request all caches be refreshed by visiting the Cache Administration page on the content server at this URL (example):
http://localhost:16200/cs/idcplg?IdcService=SSXA_GET_ADMIN_PAGE
The caching facilities in Site Studio allow for the caching of service calls. Any service call can be cached to the same location that content and metadata is currently cached. The caching facility is defined using DataBinder properties:
Specify a special parameter to enable caching.
Determine the cache key using one of the following methods:
Specify a custom cache key.
Specify the local data fields to use to generate a key.
Allow the system to calculate the cache key by using a hash of all local data.
All caching is controlled using properties set in the DataBinder. For JSP/JSPX, these properties can be added with the wcm:idcParameter tag to either a wcm:idcService call or a wcm:dynamicList call.
Parameters:
__ssxaCacheKey: Specify a cache key to use for this request. Optional.
__ssxaCacheFields: Specify a CSV list of fields to use to generate the cache key (if not specified, all local data is used). Optional.
__ssxaCacheTTL: Specify a time to live value, in milliseconds, for the cached data. If not specified, the default value of 5 minutes is used. If specified a value of 0 or less, the cache item will live indefinitely (no timeout). Optional.
Example of caching a dynamic list, with the value being refreshed every 60 seconds:
<wcm:dynamicList var="searchResponse" element="nativedocs"> <wcm:idcParameter name="__ssxaCacheEnabled" value="true" /> <wcm:idcParameter name="__ssxaCacheTTL" value="60000" /> </wcm:dynamicList>
Example of caching a GET_SEARCH_RESULTS service call:
<wcm:idcService var="dataBinder" service="GET_SEARCH_RESULTS"> <wcm:idcParameter name="QueryText" value="" /> <wcm:idcParameter name="__ssxaCacheEnabled" value="true" /> </wcm:dynamicList>
Service calls are staged into the cache directory, alongside the content, metadata and project files. The directory /idc-service is created with this directory structure:
/idc-service/service_name/user_name/cacheID.hda
This example shows a cache directory for a search results:
+- idc-service/
+- ssxa_get_dynamic_list_results/
+- anonymous/
+- 3164744485.hda
+- get_search_results/
+- anonymous/
+- 2452981209.hda