For those familiar with IBM Web Content Management development, you have probably run into situations where it would be really helpful to temporarily change the current context. For example, maybe you want to run a navigator over product group site areas, and then for each site area, run a menu over just that site area to allow for additional filtering of the sub-items. Before the Content Template Catalog was introduced, the only way you could manage this context switch was through either a custom JSP or a custom plugin, both of which require knowledge of the WCM API.
With the release of the CTC and Portal 8 and 8.5, we now have two great out of the box options to handle this case, with no need to create WCM API code. The first is the renderComponentInContext JSP. This JSP takes arguments for the context you wish to use and the component you wish to render as a field name. This way, you can use the same content type to build multiple context switched components. You simply select the content you wish to use as your new context in the ‘Context Override’ element, and the component you wish to render in the ‘Component reference’ element. This JSP also gives you some other helpful utilities, like putting the categories of the current content onto the request for reference later; in a menu, for instance.
The second tool is a tag released with CF3 in Portal 8.5 called InContext. It works very similarly to the renderComponentInContext JSP except that you get to specify the context right in the tag. You can use any of the normal contexts (current, autofill, portlet, etc…), a selected uuid, and even the path to the content item (both full and relative). Once the tag is open, everything within it functions as though the context has been switched, so you need to be even more wary of setting the correct context options in your tags.
With both of these tools, you can do some incredibly powerful things with WCM that you couldn’t accomplish before without a bunch of custom code. There are some things to watch out for, however. First, if you are switching contexts to Site Areas, you need to be sure to have default content for those Site Areas. Second, try to limit the amount of context switching you do with either tool. Once you have learned how to apply both, it can be tempting to use it all over. I suggest trying to use it only when it is really required, and when you do use it, try to accomplish as much as you can within one context switch in order to minimize the number of switches. This will help with both performance and readability in your code.
For more information, please see the following knowledge center pages on context switching: