Eval This! Creating Reusable Fragments with Site Studio

There’s a pretty clever function used in Site Studio JSP development called evalIdcScp. It’s a method on the idcserver.ServerBean and if you’ve worked with or implemented a JSP Site Studio site, you’ve undoutably run accross it more than once.

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.