A little background

In Site Studio there are two types of pages;  Primary pages, which are essentially the landing pages for a folder(think home, search and listing pages).  They are almost always named index.htm and what’s unique about them is that when they are called they only refence specific content items.  Secondary pages, which could be viewed as everything else in a folder differ as they are used in more of traditional templated, delivery fashion, where the content is delivered through a reuseable template.  I butchering those descriptions a little for simplicities sack, but for the most part that’s how they work.

Out of the box, Site Studio lets you reference a content item using it’s content id in the url.  So if you had a content item called 000525, it would be referenced in a folder with it’s content id at the end(http://SiteStudio.com/site/folder/000525 for example).  Since all templates are mapped to thier folder, everything you need to render a page can be found in the URL…it’s all pretty simple.  The thing is, what if you aren’t too crazy about the 000525 name though?  It’s not really all that intuative of a name; you could make the content id friendly or you could use also take advantage of the SSUrlFieldName property in Site Studio.  The SSUrlFieldName property allows you to map a custom metadata field(perhaps one longer than the 30 characters you get for a content id?) as the file name idenifiier used when reference in a URL.

So content item 000525 can also have a metadata field tagged as “autofillthatfriendlyname.htm” and so when refereced as a url, it could look like this: http://SiteStudio.com/site/folder/autofillthatfriendlyname.htm.  That’s pretty cool, right?  There is a bit of a catch though, like the content id the value used in the friendly name field should be unique.  The only problem though is that there’s no automatic validation for the values, so there’s nothing to tell the contributor if they’ve duplicated a value.

What the component does

The code for this component is pretty simple, we’re hooking in to the validateCheckinData event and then basically updating whatever field is identified in the SSUrlFieldName property with a friendly name.  I like the validateCheckinData filter quite bit for situations like this where I need to update or add some metadata at check in or update time.  If I have to kick a process off or do something to a piece of content that has just been checked in, so after it’s in the system, I usually prefer the afterLoadRecordWebChange, but that’s probably for another post.

Getting back on track, once a piece of content is checked in which has a xWebsiteSection value(meaning it’s been assigned a default URL in a web site), it pulls the dDocTitle value out of the binder and makes it friendly(removes any spaces or special characters I could think of).  It then appends a file extension(set in the environmental config) and checks the value against the database.  If the friendly name has been used before on another content item it goes back and adds a 1 to the end of the title part of the file name(I know…not very imaginative).  Each time the component assembles a name it checks it against a max character count also found in the component’s enviornmental config.

Installing this puppy

The install on this component is not really unlike any other.  You of course do need to make sure Site Studio is installed on your content server and that the SSUrlFieldName property has been set in the config.cfg file.  I should note that when you set the SSUrlFieldName property, you need to leave the little x prefixing all custom metadata fields off.  So no xFieldName formats…just FieldName.  You probably will need to tell the component what the size of your friendly name field is.  It’s defaulted to 80 characters, so if you  plan on using less or more, you might want to update it in the component’s environmental config file.

You can download the component here:  Auto Fill Friendly Name

As you might guess evalIdcScp stands for “Evaluate Idoc Script” and it’s purpose is to allow IDOC script execution inside of a JSP page. This is great because even though IDOC/HCSP and JSP sites utilize completely different languages, the general interation with the content server can occur in a similar way.

An example of how evalIdcScp is commonly used is with fragment parameters. Consider these two examples, one in IDOC the other in JSP:

BackgroundColor = getValue("#active",ssFragmentInstanceID + "_BackgroundColor")

String BackgroundColor = serverbean.evalIdcScp("getValue(\"#active\",ssFragmentInstanceID + \"_BackgroundColor\")");

Both examples use the IDOC function getValue to retrieve the background color parameter. While it might look a little kludgy from a Java perspective, the fact is that there are a number of functions in IDOC that are coded for specific interactions within the content server, being able to leverage those functions in Java and JSP can make things quite a bit easier.

That’s great and all but are you seriously posting about a method?

Leveraging IDOC functions in JSP is nice but hardly ground breaking. Where I think things do get a little more interesting is when you realize that evalIdcScp is less of an eval function and more of an IDOC parser.

Here’s some code for a very simple yet traditional JSP static list fragment. The fragment will render a little “call out” list, basically a vertical group of link/title and description blocks.

//get a count of the number of rows in the list
String titleCountRaw = serverbean.evalIdcScp("ssGetXmlNodeCount(SS_DATAFILE, [Root]/Title')");
//convert the count to a number
int titleCount = Integer.parseInt(titleCountRaw);

//loop through all the nodes of the static list
for(int counter=1;counter<= titleCount;counter++){
//get the title
String Title = sb.evalIdcScp("ssIncludeXml(SS_DATAFILE, '[Root]/Title[" + counter + "]/node()')");
//get the link
String Link = sb.evalIdcScp("ssIncludeXml(SS_DATAFILE, '[Root]/Link[" + counter + "]/node()')");
//get the description
String Desc = sb.evalIdcScp("ssIncludeXml(SS_DATAFILE, '[Root]/Desc[" + counter + "]/node()')");
//render the html call out. note the ugly inline html.
%>
<div><h1><a href="<%=Link%>"><%=Title%></a></h1><%=Desc%></div>
<%
}


Again a pretty basic example, but one which reveals a fundamental weaknesses in many fragment designs; The HTML is often embedded in the code. This makes creating re-usable fragments much tougher and often when attempted involves just parameterizing CSS or other HTML attributes.

Using the evalIdcpScp method we may have an additional option in designing a more flexible, reusable fragment. Using out static list example from before, let’s also assume we have a BigText fragment parameter called “CallOutHTML”. We’ll also assume that when the example static list is added to a template the following mark up is placed in the parameter(notice the embedded IDOC):

<div>
<h1><a href="<$Link$>"><$Title$></a></h1>
<$Desc$>
</div>


We’ll then make some adjustments to the static list code, this time leveraging our new fragment paramter along with the evalIdcScp method.

//get the CallOutHTML html parameter
String CallOutHTML = sb.evalIdcScp("getValue('#active', ssFragmentInstanceId & '_CallOutHTML')");
//get a count of the number of rows in the list
String titleCountRaw = serverbean.evalIdcScp("ssGetXmlNodeCount(SS_DATAFILE, [Root]/Title')");
//convert the count to a number
int titleCount = Integer.parseInt(titleCountRaw);

//loop through all the nodes of the static list
for(int counter=1;counter<= titleCount;counter++){
//get the title
String Title = sb.evalIdcScp("ssIncludeXml(SS_DATAFILE, '[Root]/Title[" + counter + "]/node()')");
//get the link
String Link = sb.evalIdcScp("ssIncludeXml(SS_DATAFILE, '[Root]/Link[" + counter + "]/node()')");
//get the description
String Desc = sb.evalIdcScp("ssIncludeXml(SS_DATAFILE, '[Root]/Desc[" + counter + "]/node()')");

//put the title, link and desc back in to the binder as local values
sb.putLocal("Title",Title);
sb.putLocal("Title",Link);
sb.putLocal("Desc",Desc);

//and now the cool part...render the list
out.println(sb.evalIdcScp("$>" + CallOutHTML + "<$"));
}

So what just happened?

• We defined a big text parameter called CallOutHTML that contained all the HTML needed to render a call out. In the spots where we needed output values we placed IDOC variables using the standard IDOC syntax(not the HCSP variety).
• We began a standard loop through the static list pulling out our values from the the data file
• Rather than rendering the values right away to the page with inline HTML, we put those values back in to the binder as local data.
• evalIdcScp was called, passing CallOutHTML in as a parameter along with some funny syntax to close out and then open IDOC script before and after our CallOutHTML string. We did this because evalIdcScp evaluates the contents of it’s only argument as IDOC script, so immediately closing out the script allows us to pass HTML through and then only render the scripts inside the string.
• The server bean then executes CallOutHTML as IDOC script and since our three values (Title, Link and Desc) are in the local binder, the IDOC parser evaluates them and injectes them in to the HTML.

If this were another system, say one that used PHP or Python as it’s scripting language, I would have a real problem with this technique. If you generate presentation via a server side eval function you need to think long and hard about where the data being evaluated comes from because If it can come from a user prompt you’ve opened your application up to injection attacks.

Fortunately for us IDOC is no python. It’s a fundamentally safe language that can’t do very much other that read values you already have access to (workflow functions being the only exception). IDOC can call services but they are secured both by permissions as well as by type of use. As a general rule, if it makes a change in UCM you can’t script it.

A Simple MVC Pattern for Fragments?

In our static list example we’ve demonstrated how to separate the layer presentation from the fragment code and implemented it in more of a template-specific manner. The static list code with it’s generic Title, Link and Desc elements can now be re-used across a many different template and web sites. Very little consideration needs to be given for how the static list will be displayed, knowing that virtually any presentation requirement can be met with the fragment. As long as the situation calls for a static list with Title, Link and Description elements this fragment can be used. While I wouldn’t start calling this an MVC framework, I think we can start to see the hallmarks and benefits of MVC design.

The current process for template development goes something like this:  Designers take their HTML and paste it in to a new Site Studio layout template, contributor areas are identified and regions/elements are added.  Functional areas of the page are broken out in to fragment controls.  It’s a fairly organic way of developing a web page, one which makes sense and is easy to understand by most everyone.  The problem for me though is that as multiple templates are added to the site, they usually employ a common structure and design of which usually a significant portion ends up having to be duplicated on each template.

A big deal?  It’s certainly not the end of the world, but perhaps there’s a more elegant method.

I’ve been tinkering with using fragments or more specifically fragment snippets a little differently then they are more commonly used right now.  Instead of pasting in the HTML directly in to the layout template like I normal, I start by creating a new “base layout” and in it I created a series of drop point, reference snippets for each of the opening and closing tags used in the structural formatting for the page.

As you can see from the table above, the fragment holds seven snippets which house the foundational structure of the template and could be re-used on every page in the site.

With the base layout fragment complete, I then created a sub layout which could be used inside the base layout’s structure.  Again nothing to fancy, it’s basically a div that contains a place to put a title and some content.

This fragment, which I am calling a container fragment, also allows for an ID attribute for the container’s div to be passed in.  This is cool because when I added the fragment to the page I did it three times; twice next to each other in between the “Start of Body” and above “Body Divider” snippets and then once after the “Body Divider” snippet.  Using CSS I set the two upper container fragments to float side by side and lower one to take up the entire lower portion of the page.

So just to recap, I created two fragments both of which contain only HTML, added them to the page 4 times(1base fragment 3 container fragments) and interspersed the container fragments in beween snippets from the layout fragment.  Looking at the template in design view, you would see that the only HTML present is the HTML,HEAD and BODY tags that the designer adds.  All HTML has been abstracted from the template.

From there I added a region to the page, wrapping it’s open and closing region tags before and after the “Start of Main” and “End of Main” snippets.  With the region in place, I then went and added elements in between the various snippets.  Between the “Start of Title” and “End of Title” snippets(both in the containers and on the page) I added text elements.  In side the container, after the “End of Title” snippets, I added WYSIWYG areas.  More traditional functional fragments like static lists or navigation could also be placed in between the layout or container snippets also.

Once the region is in, content can be assigned and the layout template can be used to render pages.  Instead of having 5-10 similar templates with similar HTML though, with this design all HTML is added once and then can be re-used multiple times.  All pages should display in a consistent format and global changes can be made to the design of all pages from a single location.

So what’s the downside?  Well there might be a performance impact, it’s just not completely clear if it’s negligible or at what point it will become noticeable.  Fragment snippets are really just nodes in an XML file which are rendered using a XPATH expression and Site Studio’s ssIncludeXML IDOC function.  The couple fragments I’ve used in my example probably aren’t going to cause a problem, but using this design has the potential to add a great many more snippets to a template then one would normally see.  How many is too many, I’m just not sure yet….so far it doesn’t seem to be a problem though.

I’m going to keep evaluating this design and will have some follow up posts down the road.  If anyone has any similar stories, post a comment or send me an email, I’d be very interested to hear your thoughts.

The one issue I’ve run in to though is when developing web sites in Site Studio I find it’s hard to tap in to all of that wonderful localization functionality without changing the default system locale.  The problem appears to be that the localization is based on the user and since all anonymous users are essentially using the same account, they all appear to have the same locale.  I’ve read some posts on how to change the user’s locale by updating a cookie, either server side or by Javascript, but to be honest I’m not super crazy about that method.  Odds are everything will work fine 99.99% of the time, but what if a user has cookies disable or if the user is actually a search crawler which is ignoring cookies? It’s probably not going to work so well.

Enter the IdcLocale object

Changing the user’s locale during a service execution is actually an extremely easy thing to do.  Localization data is held in the IdcLocale object(intradoc.common package), which is stored during exection as a cached object named “UserLocale”.  If you wanted to access a user’s IdcLocale object, the syntax looks something like this:

IdcLocale MyLocale = (IdcLocale)context.getCachedObject("UserLocale");

Changing the locale take a couple more steps.  You first need load a new IdcLocale object specific to your locale and then you need to overwrite the old one.  Creating a new IdcLocale object is pretty simple, you use the LocaleResources object and call the static method, getLocale.  It takes a single argument, the name of the Locale you’re loading:

IdcLocale ItalianLocale = LocaleResources.getLocale("Italiano");

Once you have the new IdcLocale object, you only need to overwrite the old one and your locale is changed :

context.setCachedObject("UserLocale", ItalianLocale);

Putting it in action

I’ve put together a sample component which adds functionality for changing the user’s locale dynamically.  In tinkering with user locales, there are two customizations which I think can come in handy.

The first is customization is a filter attached to the ‘afterInitLocale’ event, which is fired right after the user’s locale is set during a service call and I’m pretty sure was put there specifically for changing the locale. In the component, the filter looks for a local binder value called ForceUserLocale. If it’s there and it’s a valid Locale name, then it swaps out the current user’s IdcLocale object with a new one. Post-switch, the service continues it’s execution evaluting the new Locale object.

The other customization basically wraps that same code in a new IDOC script function called setLocale. SetLocale takes a single argument, LocaleName, which is of course the name of a valid locale in the system. Calling the function immediatly switches out the user’s Locale with a new one. This is pretty cool if you’re working on a web page or template and wish to show the same or multiple strings in different languages.

Using the new setLocale function, the following code would display the same string on the same page in different languages:
<$setLocale("Italiano")$>
<$lc("wwPoweredBy")$>
<$setLocale("Italiano")$>
< $lc("wwPoweredBy")$>

Controllato dal sistema di gestione dei contenuti
Powered by Content Management System

Changing the Locale dynamically with a local binder value might not be the best fit for all implementations. If you install the sample component adding ForceUserLocale=Italiano to the URL will change the locale to Italian, which may or may not be undesirable. Nevertheless, I think the component demostrates some of the cool things you can do with the IdcLocale object.

The sample Anonymous User Locale component is can be downloaded here:
Anonymous User Locale Component

Use Real Names for Section IDs

Starting work on a new site, my first step is to go through and set up the known folder structure of the site.  This usually only takes a little while, but it helps me visualize how everything will work as I’m developing.  One thing that’s very important to me during this step and really throughout the build is to ensure I’m using logical names for the section ids and not just the default numerical ones that the designer will assign.  Down the road when debugging fragments or even reviewing content in the repository, numbers as section ids can be very confusing and will probably cost more time the it takes to just give them logical names.

Create a Templates Folder

When I am building out the site’s folder structure I also like to create a contributor-only templates section.  There I add a section for each template the site will use, actually creating the template and assigning it to the section during the process.  Often I will break up the template sections by how they are used, adding primary and secondary template parent sections.  If I have any html ready, I paste it in to the templates, adjusting any css, javascript or image paths during the process.

The templates folder allows me to get all my templates in and assigned to the site, but in a central location.  Templates can be added as a site asset, so this is a bit redundant, but having them in a folder allows me to assign region content, test custom properties and potentially navigation as well.

Use Fragments for Images, Javascript and CSS

When I start work on a site I usually have the luxury of receiving all of my html, css and some of my javascript pre-built from our user experience group which means I am not doing any serious HTML development in Site Studio other then some simple tweaks.  Since that’s the case, there’s no good reason for me to load what could be hundreds of individual site assets in to the content server.  It’s much easier just to load each set of assets in to fragments and then check them in that way.  In addition you can preserve any folder structure the assets already have, making tweaks to the template html a bit easier too.  Loading each asset individually is perfectly fine, but I thinks far easier and a little cleaner in the content server to load them in fragments.

When you save the fragments it’s assets are written out to the weblayout/fragments folder.  Once those assets are there, I just create a single “head” fragment which references the nessecary items from css and javascript assets, never actually referencing the css or javascript fragments.

One Fragment per Library 

I’m a fan of creating a new library for each fragment in my site.  I’ve done this differently in the past, creating more contextual libraries with multiple fragments, but I’m much happier now with the one fragment per library way.  Right off it’s much easier to manage fragment development with multiple developers.  Multiple fragments in a single library means that one developer can check out a library at a time thereby preventing other developers from working on other fragments in the same library.  

My biggest reasoning though has to do with change management.  If there are multiple fragments in a library all of them must be production ready to deploy.  You easily can find yourself in a situation where a change is occurring on one fragment, when a bug or another emergency change needs to happen on another.  If all the fragments are in the same library it can become a confusing mess.  If you stick with one per library you may have a few more libraries in the content server, but you’ll also have a great deal more flexibility.

Debug that JSP

This next part can be a little tricky and from an Oracle perspective is probably a bad practice.  Generally whenever I set up a new development environment also set up eclipse to debug the content server as well.  Bex Huff’s book “The Definitive Guide to Stellent Content Server Development” details how to configure eclipse for debugging so I am not going to cover that process here.  What I will talk about though is that if you are running a version of Eclipse with JSP support, you can also debug JSP fragments and layout templates just as easily as filters and service handlers.

This sounds great, but you have to remember that if you’re debugging and editing your fragments through eclipse, ultimately you’re also doing it in the content server’s area of the file system.  If you’re not careful this is an excellent way to loose your work.  If anyone else edits your fragment library or if they deploy your fragment through the Site Studio fragment administration page, any changes you’ve made on the file system will be immediately overwritten.  To counter the threat of loosing my changes, I make sure I always check out each item I’m debugging and frequently save my changes back to the fragment using the designer.  All that said, being able to debug with eclipse can make development so much easier the rewards far outweigh the risks. 

To set up JSP debugging, first follow the steps in Bex’s book to set up your eclipse environment and then just link the weblayout folder to your content server project.  From there you’ll find your fragment JSPs in the weblayout/groups/[your jsp enabled security group]/WEB-INF/fragments/[fragment name] folder.

Some of the highlights so far:

1. There is a new web-based Site Studio editor coming out in the next few months to replace the existing activex one.  Personally this was huge for me as the IE only aspect of the existing editor has always been a pain point with some of my clients who prefer macs.  In general the editor was pretty slick.  It appears as a pop-up when you click the in-context edit button and has a tabbed interface allowing you to contribute content on one tab and update metadata on the other.  They’ve also added some additional validation which can be configured to require specific standards compliance when contributing.

 2. The WCMA project appears to now be called Open WCM and it looks to be very cool.  Not much of a demo this time, but more of an architectural discussion.  The concept is to allow web content management delivery on any platform, using any language..hence the open part.  In addition they also would like to take the content server out of the delivery environment, moving to more of a hybrid publishing model, which can be consumed by your web app.

 3. During the digital asset management session, we got a nice demo of what you can do with the Folios component that was released just last week.  Folios is very, very cool new feature which allows you to relate several content items together and have them become an additional new item in the system.  You’re new folio then can be associated with metadata, sent through workflow for approvals or, depending on the formats, published as a compound document.

Also very cool are some of ideas on how they plan on integrating Content Server with the other application in the Fusion Middleware stack.  There seems to be a big focus on delivering personalized, targeted content using Seibel profiles and Oracle’s Real Time decisioning application(part of the BI suite).  All of that is just conjecture at this point, but still very cool to hear they were working on it.

Scriptaculous is built on Prototype which is an independent Javascript framework used by several libraries in addition to Scriptaculous. Prototype’s claim to fame is the $() function, which is used to reference html elements and is far easier to type than document.getElementById().  The framework is chock full of functionality to make your life easier and also provides an abstraction layer to the browser so Prototype handles any compatibility issues for you.

Here’s a couple of my favorite Prototype functions:

//returns all elements which have a specified css class
document.getElementsByClassName([class name]);

//attaches a function to an object event
Event.observe([object],[event name],[function]);

//converts the input fields of a form in to an Ajax compatible query string format
[Form Object].serialize();


The Scriptaculous library then has an additional set of utilities, controls and my favorite the effects.

Couple of my favorite Scriptaculous Functions:

Effect.Fade($("testdiv"))
Effect.Appear($("testdiv"))
Effect.BlindDown($("testdiv"))


All of this brings me to Stellent/Oracle who actually have a Javascript preference of their own, the Yahoo YUI library.  I am also a big fan of YUI, but it’s much more of a control library then a framework.  This has caused problems for me when working with 3rd party web designers who are not developing HTML specifically for YUI.  Scriptaculous on the other hand often works great regardless of how the HTML is designed.  Both libraries can live harmoniously on the same page and I’ve often found myself using the Prototype $() function to reference YUI controls.

Oracle/Stellent implements the YUI library using a component which places their Javascriptand CSS files in the weblayout/resources folder.  Using that same concept, I put together a quick and dirty Scriptaculous component which does the same.  In addition there’s a  resource override of the std_html_head_declarations include, where I’ve added a reference to the library, making it globally available in the Content Server UI. That component is available for download here and it includes the latest release version of Scriptaculous 1.7.0.

Updated: 11/10/2007 – The latest Oracle / Stellent Script.aculo.us component(version 1.8) may be downloaded here:

Script.aculo.us Component for Oracle / Stellent Content Server

Personally I find the renamed DOC_INFO method to be effective, but also a bit clunky.  I don’t like the idea of needing code on the page in order make my fragment work properly.  I’m even less of a fan of using the DOC_INFO_BY_NAME service.  The service consists of twelve actions which check, set and return values, 99% of which you will not need, just to get the DOC_INFO resultset, which was already loaded with the page(twice) prior to loading the fragment.  One or two fragments on a page calling the DOC_INFO_BY_NAME service probably won’t cause much of a problem, but add a few more and you’ll notice a perceptible delay in your load time.

What I’ve been looking for is a way to create fragments which can utilize the content region’s metadata, not cause a preformace drag on my page and also allow me to encapsulate all of my code in the fragment.  I want to just drop the fragment on the page and watch it magically start working.  Bonus:  I need it to work in IDOC or JSP.  Does Stellent have an out of the box way to answer this need?  I haven’t found one but there really should be, not only because it makes sense, but because they already have most of the code in place to support this functionality.

In the Site Studio classes folder there’s a class called SSCommon, which appears to provide a set of common(go figure) functions for Site Studio.  There are quite a few methods in the class, but two of them stand out, “getDocInfo” and “createCachedResultSet”.  Apply a little deductive logic, a little testing and you’ll quickly find that calling “getDocInfo” will retrieve or create a cached DOC_INFO resultset.

To make calling getDocInfo a bit easier as well as possible in IDoc,  I’ve created a component which adds an IDoc function called “ssGetCachedDocInfo”.  The code is pretty simple, remember Stellent/Oracle has done most of the work for us.

//create a new binder so we don't overwrite the fragment's doc_info
DataBinder CacheBinder = new DataBinder();
//call getDocInfo from SSCommon
SSCommon.getDocInfo(dDocName, service, CacheBinder, false, null);
//Retrieve the new DOC_INFO resultset
ResultSet myResultSet = CacheBinder.getResultSet("DOC_INFO");
//Create a dataresultset so we can save it
DataResultSet myResultSetdr = new DataResultSet();
myResultSetdr.copy(myResultSet);
//add it to the binder with a new name
binder.addResultSetDirect("DOC_INFO_" + dDocName, myResultSetdr);

As you can see the new Idoc function, ssGetCachedDocInfo, uses the getDocInfo method to retrieve the cached DOC_INFO resultset and then places it back in to the binder named DOC_INFO_ followed by the content id of the item.  I’ve left out all the code used to support an IDoc function, but the full version is available for download.

To test the ssGetCachedDocInfo function, create a new IDoc fragment and add the following code to a drop point/reference snippet.

Content ID: <!--$dDocName-->
Title: <!--$dDocTitle-->
Security Group: <!--$dSecurityGroup-->
Type: <!--$dDocType-->
<!--$endloop-->

<!--$result = ssGetCachedDocInfo(region1)-->
<!--$if rsExists("DOC_INFO_" & region1)-->
<!--$result = rsFirst("DOC_INFO_" & region1)-->
Content ID: <!--$getValue("DOC_INFO_" & region1,"dDocName")-->
Title: <!--$getValue("DOC_INFO_" & region1,"dDocTitle")-->
Security Group: <!--$getValue("DOC_INFO_" & region1,"dSecurityGroup")-->
Comments: <!--$getValue("DOC_INFO_" & region1,"xComments")-->
Type: <!--$getValue("DOC_INFO_" & region1,"dDocType")-->
<!--$endif-->

Add the fragment to a page with a content region and you’ll see the results.  The first block of code will retrieve and display the active DOC_INFO resultset, which will relate to the fragment not the region’s content item.  The second block executes the new ssGetCachedDocInfo IDoc function and retrieves the region’s metadata.  If you run a couple of SQL traces before and after adding the fragment to the page, you’ll note the lack of any additional doc info queries.

Since creating the function, we’ve found quite a few uses for it.  I’ve used it to create a related links call out, which uses the content region’s metadata in a search call to build a dynamic list of links in the site which relate to the content area.  I’ve also created a title fragment, which builds out the title tag dynamically for my pages, using the content region’s title.  Most interestingly though was what one of my colleagues did, which was use the function to retrieve cached metadata for items in a static list and therefore not actually found in a region on the page.

Feel free to download the component and the code here.