When developing a site that uses SEO, you must be careful about whether the generated URLs should include the application’s context path. Dynamic URLs must include the context path (so that these URLs are properly interpreted by ATG’s request-handling pipeline). Static URLs do not need the context path (the URL is never actually interpreted by the pipeline), and it is better to omit it because it may interfere with the jump servlet’s ability to detect static URLs in requests. This is because the urlTemplateFormat property of an indirect URL template will typically start with a special string (such as /jump) that enables the jump servlet to detect these URLs. The jump servlet should then be configured to use URI-mapping to detect these URLs, as described in Configuring the SEO Jump Servlet.

Therefore, when ItemLink generates an indirect URL, it is undesirable for the application’s context path to be prepended to the URL. To avoid including the context path, links created with the <dsp:a> tag should use the href attribute, not the page attribute. The page attribute prepends the application’s context path to the generated URL, but the href attribute does not.

However, using the href attribute means that the context path will not automatically be prepended to the dynamic URLs generated by ItemLink. Also, since static URLs won’t have the context path, the jump servlet will not be able to include this information in the dynamic URLs it forwards inbound requests to. Therefore, you should include the context path when you configure the following:

  • The urlTemplateFormat property of each direct URL template

  • The forwardUrlTemplateFormat property of each indirect URL template

There are two ways you can specify the context path:

  • Explicitly include the context path when you set the property.

  • Specify the name of a registered web application. There must be a single colon character after the web application name to denote that it is a web application name.

Specifying the name of a registered web application rather than including the context path itself has the advantage that you don’t need to know what the context path actually is. Also, if the context path changes, you don’t need to update each URL template component. The main disadvantage is that you need to know what web application registry the web application is registered with, and set the webAppRegistry property of each URL template component to this value.

When generating a direct URL (either with ItemLink using a direct template, or the jump servlet using the forward URL in an indirect template), the following logic is used to determine the context path:

  1. If a web application name occurs in the first part of the URL with the format webAppName:restOfUrl, the web application is resolved using the web application registry specified in the webAppRegistry property of the template. The web application’s context path is then used to replace the webAppName placeholder.

  2. If there is a colon in the first part of the URL but no web application name before the colon, the context path of the default web application is used. The default web application is specified in the defaultWebApp property of the ItemLink servlet bean or of the jump servlet (the former if generating a direct URL for a page link, the latter if generating a forwarding URL for an inbound request).

  3. Otherwise, the context path is assumed to already be present.

 
loading table of contents...