Oracle/Stellent Site Studio Doc Info Caching

One of the things I’ve struggled with when developing fragment controls in Site Studio is; what’s the best way to get the metadata for the content region while in a fragment?  The problem has been that while a fragment is being executed, it’s metadata overrides the metadata related to the content region.  Logically this make some sense, the content region’s document and the fragment are both content items in the repository, one would assume that metadata is required to render them both.  But what’s the best way to get that metadata from the content region’s document?  I’ve seen a couple examples where users create a renamed copy of the content region’s DOC_INFO resultset on the page, but I suspect the most common technique is to simply call the DOC_INFO_BY_NAME service in each fragment using the region id as the dDocName.

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.