4 Link Formats

This section covers the following topics:

4.1 About Link Formats

There are many ways to make a link in Site Studio. You use the expected HTML path-based link, as well as some Site Studio extensions that maximize the portability and reusability of the architecture in Site Studio 11g.

Within the Site Studio-specific methods, there are three main types of links. There are links to a content file (such as a data file or a native document), links to a node, and links to a static resource, such as an image.

4.2 Using Path-Based Links

A path-based link is simply a link using a path. You can use Idoc Script variables to replace a section of the path if you wish. The variable will be evaluated by the server and replaced in the served HTML.

Path-based links can be written as absolute or relative. Relative links, as well as links using an Idoc variable, are recommended because they are more portable. Absolute links are very easily broken when the site is modified. The only time an absolute link is recommended is when linking to an outside website.

When a path-based link is created using the Link Wizard, the portion of the path from the server to the web site root is replaced with an Idoc variable.

Examples

The basic path-based link is a full URL just as expected:

support/index.html

The same link created using an Idoc variable (specifically ssServerRelativeSiteRoot) would look like this:

<!--$ssServerRelativeSiteRoot-->support/index.html
<a href="[!--$ssServerRelativeSiteRoot--]support/index.html">

Note that the content in the variable includes the final "/" in the path segment.

Relative paths are used as they would be in any static HTML instance:

../../support/index.html
<a href="../../support/index.html">

In some examples, you may see the angle bracket used (for example, <!--$wcmUrl('nodelink', '30)-->), and in other examples, you may see the square bracket used ([!--$wcmUrl('nodelink', '30)--]. Site Studio writes the square bracket to XML files and other places where an angle bracket might cause escaping problems, and it writes the angle bracket to templates. You should know that they can be used interchangeably; however you should keep in mind which instance might cause a problem with escaping when you choose to use one or the other.

4.3 Using Server-Side Script Links

A server-side script link is a link that is written in script, but is then evaluated by the server and replaced in the displayed HTML. If someone chooses to view the source of the displayed page, they will only see the URL (either a relative or a full URL).

The server-side script links are written in Idoc Script. Whether it is a variable or a function call, the server-side link evaluates on the server and you will never see it in the displayed Web page's source.

Contains these topics:

4.3.1 wcmUrl

This is a script-extension designed to encapsulate the other link forms, specifically the server-side ssNodeLink, ssLink, and ssWeblayoutUrl. This is the recommended link format to use with Site Studio.

It only requires one parameter, the type. The other parameters may or may not be required depending on the type specified.

The wcmUrl script extension is a server-side script link that incorporates the functionality of the script links listed in Section 4.3, "Using Server-Side Script Links." Maintaining them all using one script extension makes it easier to search out the links in a content file or template.

Parameters

  • type: the type of link, entered as one of the following:

    [nodelink | link | resource]

    Nodelink is used to create links to sections, which by default end with index.htm. Link is used to create links to content, which by default end with contentId. Resource is used to link to weblayout static resources, such as images.

  • nodeId: the ID of the node referenced. Used only when the type is set to either nodelink or link.

  • siteId: the site ID of the web site referenced. Used only when the type is set to either nodelink or link.

  • dDocName: the dDocName of the content referenced. Used only when the type is set to either link or resource.

Examples

Before evaluation:

[!--$wcmUrl('link', 'switched_region_CDF')--]
[!--$wcmUrl('nodelink', '30')--]
[!--$wcmUrl('resource' 'groups/public/documents/adacct/mydocname.jpg')--]

These examples use single quotes for the parameters. Other examples may show double quotes. Both work, however, just as with the angle bracket and square bracket, there may be some instances where using one instead of the other will help prevent possible escaping problems.

Evaluated by the server:

<a href="/support/switched_region/">
<a href="/region/West/">
<img src="groups/public/documents/adacct/mydocname.jpg">

The first line shows a link to a content file referenced by the dDocName, the second is a link to a node referenced by the nodeId, and the third is a path to an image file on the Oracle Content Server.

If a value for a link evaluates as bad, such as when it is linked to a resource that is no longer there, then the link evaluates as a token link. For more information, see Section 4.4.3, "Token Links Generated From Returned Server-Side Links."

4.3.2 ssLink

The ssLink script link is used to create a server-side link to a data file, such as a native document. The target object is referenced by the dDocName.

Parameters

  • dDocName: the dDocName of the managed item. If only one parameter is specified, it is assumed to be the dDocName.

  • targetNodeId: a unique identifier for a node to use as the target context (optional).

  • targetSiteId: the unique identifier for the web site to use as the target context (optional). If you do wish to specify a targetSiteId, you must also specify the targetNodeId.

Examples

Before evaluation:

[!--$ssLink('dDocName')--]

(where the dDocName refers to a content file at /support/switched_region)

Evaluated by the server:

<a href="/support/switched_region/">

Note:

If the link generated by ssLink is bad, then a tokenized link using ssLINK will be used in its place. This means that a broken link will not stop the page from being generated and delivered, but the broken link is still discoverable if clicked on.

4.3.3 ssNodeLink

The ssNodeLink script link is used to create a server-side link to a web site section.

Parameters

  • nodeId: a unique identifier for a node.

  • siteId: a unique identifier for the web site containing the node (optional).

Examples

Before evaluation:

[!--$ssNodeLink('30')--]

(where the /support/CRM folder on the web site has a nodeId of 30)

Evaluated by the server:

<a href="/support/CRM/index.htm">

Note:

If the link generated by ssNodeLink is bad, then a tokenized link using ssNODELINK will be used in its place. This means that a broken link will not stop the page from being generated and delivered, but the broken link is still discoverable if clicked on.

4.3.4 ssWebLayoutUrl

The ssWebLayoutUrl is used to create a server-side link to a weblayout rendition of the document. This resource/rendition can be referenced by either the dDocName or the path to the resource.

Parameters

  • dDocName: the dDocName of the content referenced.

Examples

Before evaluation:

[!--$ssWebLayoutUrl('groups/public/documents/adacct/mydocname.jpg')--]

Evaluated by the server:

<a href="groups/public/documents/adacct/mydocname.jpg">

4.4 Using Token Links

Token links (also known as late-resolving links) are not resolved until they are actually clicked. View source would reveal a URL that has ssLINK or ssNODELINK in the URL. Token links are not resolved until they are clicked (thus the term "late-resolving," as the link resolution happens after the page is served). By comparison, the script links are resolved on the server before serving the Web page.

You should be aware that ssLINK and ssNODELINK are token links; although ssLink and ssNodeLink have the same name as ssLINK and ssNODELINK, the camel case ssLink and ssNodeLink are script links.

Token links are a recommended way of including a link in a native document. Because the Word doc goes through Dynamic Converter and converts to HTML, it is much easier to write them with token links. It is possible otherwise, but this way is simpler.

This section contains these topics:

4.4.1 ssLINK

Used to create a late-resolving link to a data file. Unlike ssLink, the late-resolving link is not resolved until the link is clicked.

Parameters

  • dDocName: the dDocName of the managed item. If only one parameter is specified, it is assumed to be the dDocName.

  • targetNodeId: a unique identifier for a node to use as the target context (optional).

  • targetSiteId: the unique identifier for the web site to use as the target context (optional). If you do wish to specify a targetSiteId, you must also specify the targetNodeId.

Examples

Before evaluation:

<!--$ssLINK('dDocName')-->

Evaluated by the server:

<a href="ssLINK/dDocName">

Note that the ssLINK is still in the URL. It will be visible this way to any browser, either by hovering on the link or by viewing the source. Once the link is clicked, the Oracle Content Server will evaluate the dDocName, determine what the friendly URL would be, and redirect to it.

4.4.2 ssNODELINK

Used to create a late-resolving link to a web site section.

Parameters

  • nodeId: a unique identifier for a node. If only one parameter is specified, it is assumed to be the nodeId.

  • siteId: a unique identifier for the web site containing the node (optional). If you specify a siteId, you must specify a nodeId.

Examples

Before evaluation:

<!--$ssNODELINK('10027')-->

Evaluated by the server:

<a href="ssNODELINK/10027">

Note that the ssNODELINK is still in the URL. It will be visible this way to any browser, either by hovering on the link or by viewing the source. Once the link is clicked, the Oracle Content Server will evaluate the nodeId, determine what the friendly URL would be, and redirect to it.

4.4.3 Token Links Generated From Returned Server-Side Links

Token links are returned in situations where the server-side link (for example, ssNodeLink) fails. The replacement is done to ensure that the page delivery is not hampered by a bad link.

When the server evaluates the server-side link, and the link is faulty (for example, the dDocName is bad), then the server returns the link parameter value with the token link. The result is that the Web pages are still delivered without substantial errors, however, the users will then see the token link in the source (or by hovering their pointer on the link), just as they would if a token link had normally been used.

Example

The parameter value for the passed server-side link is retained. If the following is passed to the server to evaluate:

<!--$ssLink('Bad_dDocName')-->

then the server will return, in the source of the served Web page

<a href="ssLINK/Bad_dDocName">

This prevents the server from erroring out the entire Web page when trying to evaluate the link. Clicking the returned tokenized link, however, will display an error page from the server.

This will also happen for any wcmUrl script errors, as in these cases the wcmUrl is a thin wrapper for the server-side script link.

4.5 Using JavaScript Links

It is possible to use JavaScript to enter a link in a site asset. This is not recommended, but is still available as a possible method.

The links are used just as you would use ssLINK or ssNODELINK, with the same parameters. And like ssLINK and ssNODELINK, JavaScript links are late-evaluated. The only difference is in explicitly calling them as JavaScript.

Examples

javascript:link('dDocName')
javascript:nodelink('nodeId')