In our last post in this painful series, I shared some code that will resolve the ALUI / WCI Knowledge Directory links so that users can right-click and copy the links, and the files open as expected when clicked.

Since then, I’ve found that when an admin is in EDIT mode in the Knowledge Directory, the link calamity continues, and a completely different and incomprehensible linking mechanism is used. So for your reading pleasure today, I’ll update that post to handle edit mode as well as browse mode. Again, just add the following HTML to the footer used in your Knowledge Directory (depending on Experience Definition, there may be more than one):

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
<pcs:value expr="text"></pcs:value>

<pt:common.transformer pt:fixurl="off" xmlns:pt='http://www.plumtree.com/xmlschemas/ptui/'/>
<script>
try
{
       // KD BROWSE Mode
       // <a href="#" onclick="var currentWin = PTCommonOpener.openInNewWindow ('', 'Opener_18_1214986', 800, 600, true); currentWin.location= 'http://portal.integryst.com/portal/server.pt /document/1214936/DocName'; return false;">DocName</a>
       if (document.title=="Directory")
       {
              // get all links
              var anchors = document.links;
              for (x=0; x<anchors.length; x++) {

                     // get only those with an onclick event
                     onclickJS = anchors[x].onclick;
                     if (onclickJS != null)
                     {
                           onclickJS = "" + onclickJS;
                           var locCommonOpener = onclickJS.indexOf("PTCommonOpener.openInNewWindow");
                           var locpos = onclickJS.indexOf("currentWin.location");

                           // only process links that have the broken PTCommonOpener.openInNewWindow
                           if ((locpos>=0) &amp;amp;&amp;amp; (locCommonOpener>=0))
                           {
                                  // extract the URL from the broken onclick function
                                  var url = onclickJS.substr(locpos);
                                  var locstart = url.indexOf("'");
                                  if (locstart>=0)
                                  {
                                         url = url.substr(locstart+1);
                                         var locend = url.indexOf("'");
                                         if (locend>=0)
                                         {
                                                // update the URL by clearing the onclick and setting the URL to open in a new window
                                                url = url.substring(0,locend);
                                                anchors[x].href=url;
                                                anchors[x].target="_new";
                                                anchors[x].onclick=null;
                                         }
                                  }
                           }
                     }
              }
       }

       // KD Edit Mode
       // <a href="#" onclick="var currentWin = PTCommonOpener.openInNewWindow ('', 'Opener_18_1214986', 800, 600, true); currentWin.location = PTCommonOpener.getOpenerURLOpenObjID (18, 1214926, '', 2); return false;"> DocName </a>
       if (document.title=="Edit Directory")
       {
              // get all links
              var anchors = document.links;
              for (x=0; x<anchors.length; x++) {

                     // get only those with an onclick event
                     onclickJS = anchors[x].onclick;
                     if (onclickJS != null)
                     {
                           onclickJS = "" + onclickJS;
                           var locCommonOpener = onclickJS.indexOf("PTCommonOpener.openInNewWindow");
                           var locpos = onclickJS.indexOf("currentWin.location");

                           // only process links that have the broken PTCommonOpener.openInNewWindow
                           if ((locpos>=0) &amp;amp;&amp;amp; (locCommonOpener>=0))
                           {
                                  // extract the URL from the broken onclick function
                                  var url = onclickJS.substr(locpos);
                                  var locstart = url.indexOf("=");
                                  if (locstart>=0)
                                  {
                                         url = url.substr(locstart+1);
                                         var locend = url.indexOf(";");
                                         if (locend>=0)
                                         {
                                                // update the URL by clearing the onclick and setting the URL to open in a new window
                                                url = url.substring(0,locend+1);
                                                anchors[x].href=eval(url);
                                                anchors[x].target="_new";
                                                anchors[x].onclick=null;
                                         }
                                  }
                           }
                     }
              }
       }
}
catch (err)
{
       // ignore errors
}
</script>

On a completely unrelated note, thanks to my wonderful numbering scheme of these posts, I can now count to four in French…

See the docs for IPTSearchRequest and PT_SEARCH_SETTING for more options in developing your own search killer app.

// get the folder ID to load the grid data
string searchQuery = Request.Params["query"];

if (searchQuery == null)
return; // do nothing if there's no query

ArrayList userGroupResults = new ArrayList();
int classid, objectid;
string classname, objectname;

// get the portal session from the HTTPSession
PortalSessionManager sessionManager = PortalSessionFactory.getPortalSessionManager(Session, Request, Response);
IPTSession ptSession = sessionManager.getAPISession();

//search for users and groups that match this query
IPTSearchRequest request = ptSession.GetSearchRequest();

//turn off requests for collab/content apps
request.SetSettings(PT_SEARCH_SETTING.PT_SEARCHSETTING_APPS, PT_SEARCH_APPS.PT_SEARCH_APPS_PORTAL);

// Restrict the search to users and groups
request.SetSettings(PT_SEARCH_SETTING.PT_SEARCHSETTING_OBJTYPES, new int[] {PT_CLASSIDS.PT_USER_ID, PT_CLASSIDS.PT_USERGROUP_ID});

// Restrict the search to specific folders
request.SetSettings( PT_SEARCH_SETTING.PT_SEARCHSETTING_DDFOLDERS, objectFolder);
request.SetSettings( PT_SEARCH_SETTING.PT_SEARCHSETTING_INCLUDE_SUBFOLDERS, 1);

// make sure the appropriate fields are returned.
request.SetSettings(PT_SEARCH_SETTING.PT_SEARCHSETTING_RET_PROPS, new int[] {
	PT_PROPIDS.PT_PROPID_OBJECTID,
	PT_PROPIDS.PT_PROPID_CLASSID
});

// set search order
request.SetSettings(PT_SEARCH_SETTING.PT_SEARCHSETTING_ORDERBY, PT_PROPIDS.PT_PROPID_CLASSID);
IPTSearchQuery query = request.CreateBasicQuery(searchQuery + "*", "PT" + PT_INTRINSICS.PT_PROPERTY_OBJECTNAME);

IPTSearchResponse results = request.Search(query);

UserGroupObject tempRes;
int numUsersGroupsFound = 0;

// iterate the results
for (int x = 0; x < results.GetResultsReturned(); x++)
{
	objectname = results.GetFieldsAsString(x, PT_INTRINSICS.PT_PROPERTY_OBJECTNAME);
	objectid = results.GetFieldsAsInt(x, PT_INTRINSICS.PT_PROPERTY_OBJECTID);
	classid = results.GetFieldsAsInt(x, PT_INTRINSICS.PT_PROPERTY_CLASSID);
	classname = GenericObject.getClassNameFromID(classid);

	// search filter doesn't seem to work; make sure the classid is user or group
	if ((classid == PT_CLASSIDS.PT_USER_ID) || (classid == PT_CLASSIDS.PT_USERGROUP_ID))
	{
		// do stuff
	}
}

Instead, let’s look at an alternate approach:  use the Collab Server as a sort of REST API.  It’s not really, but the basic idea is that you use URLs in your code to directly call functionality in Collaboration Server to do certain tasks.  For example, say you want to add a Collaboration project to a page programmatically; there is no mechanism to do this through the IDK, and we have no idea how to use the API, but using a header tool, we find that through Project Explorer, it works with a simple URL: /collab/do/project/selector/add?commPage=true&projID=COLLABID.

So, it turns out we can do the same thing programmatically, by using Java’s network libraries to call that URL directly (setting the proper authenticationid).  The code after the jump shows an example of how to do this; we use this approach in Integryst’s Automater, which allows you to script a bunch of actions at a time (what good is automatically creating a collab project if you can’t add it to a community page you just created!?). 

Tweak away!

int collabID = ParamHelper.getIntParamValue(getInputs(),"collabid",-1);
int communityID = ParamHelper.getIntParamValue(getInputs(),"communityid",-1);
String wsapi = ParamHelper.getParamValue(getInputs(),"wsapi");

String response = "";

LOG.info("> Add Collab Project to Community. Params [collabID=" + collabID + ", communityID=" + communityID + "]");

// the IDK doesn't provide methods for attaching messages to documents, so we use HTTP methods to do that
// collab settings for direct connection
String host = ParamHelper.getParamValue(getInputs(),"collab.host");
String port = ParamHelper.getParamValue(getInputs(),"collab.port");
String user = ParamHelper.getParamValue(getInputs(),"collab.user");
String pass= ParamHelper.getParamValue(getInputs(),"collab.pass");

// these may not be needed...
String imageserver = ParamHelper.getParamValue(getInputs(),"collab.imageserverurl");
String gadgetid = ParamHelper.getParamValue(getInputs(),"collab.gadgetid");
String pageid = ParamHelper.getParamValue(getInputs(),"collab.pageid");
String userid = ParamHelper.getParamValue(getInputs(),"collab.userid");
String username = ParamHelper.getParamValue(getInputs(),"collab.username");

String addr = "http://" + host + ":" + port + "/collab/do/project/selector/add?commPage=true&projID=" + collabID;

try{
LOG.debug("Attempting Collab Connection to " + addr);
URL url = new URL(addr);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
String encoding = new sun.misc.BASE64Encoder().encode((user + ":" + pass).getBytes());
conn.setRequestProperty ("Authorization", "Basic " + encoding);
conn.setRequestProperty ("CSP-Aggregation-Mode", "Multiple");
conn.setRequestProperty ("CSP-Activity-Rights", "uri%u003A%u002F%u002Furi%u002Ecollaboration %u002Eplumtree%u002Ecom%u002Factivity%u002Fviewpresence,uri%u003A%u002F %u002Furi%u002Ecollaboration %u002Eplumtree%u002Ecom %u002Factivity%u002Fbulkupload,uri%u003A %u002F%u002Furi%u002Ecollaboration%u002Eplumtree%u002Ecom%u002Factivity %u002Fmanagecollab,uri%u003A%u002F%u002Furi %u002Ecollaboration %u002Eplumtree%u002Ecom%u002Factivity %u002Fmanagecollabprojects");
conn.setRequestProperty ("CSP-Gateway-Specific-Config",
"PT-User-Name=" + username + "," +
"PT-User-ID=" + userid + "," +
"PT-Community-ID=" + communityID + "," +
"PT-Gadget-ID=" + gadgetid + "," +
"PT-Gateway-Version=2.5," +
"PT-Content-Mode=1," +
"PT-Time-Zone=America%u002FNew%u005FYork," +
"PT-Imageserver-URI=" + imageserver + "/," +
"PT-User-Charset=UTF-8," +
"PT-Page-ID=" + pageid + "," +
"PT-Community-ACL=15," +
"PT-SOAP-API-URI=" + wsapi + "," +
"PT-Class-ID=43," +
"PT-Guest-User=0");

conn.setRequestProperty ("USER-AGENT", "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2)");
conn.setRequestProperty ("CSP-Gateway-Type", "Plumtree");
conn.setRequestProperty ("CSP-User-Info", "FullName=" + username);
conn.setRequestProperty ("CSP-Protocol-Version", "1.3");
conn.setRequestProperty ("Accept-Language", "en-us");
conn.setRequestProperty ("CSP-Can-Set", "Gadget-User,User,Gadget-Realm,Realm");
conn.setRequestProperty ("Host", host + ":" + port);
conn.setRequestProperty ("ACCEPT", "*/*");
conn.setRequestProperty ("Accept-Encoding", "gzip");
conn.setRequestMethod("GET");

conn.connect();

// read the headers
for (int i=0; ; i++) {
String headerName = conn.getHeaderFieldKey(i);
String headerValue = conn.getHeaderField(i);

if (headerName == null && headerValue == null) {
// No more headers
break;
}
if (headerName == null)
LOG.debug("Response: " + headerValue);
else
LOG.debug("Response Header: " + headerName + ": " + headerValue);
}

InputStream in = conn.getInputStream();

// read the response
BufferedReader reader = new BufferedReader(new InputStreamReader(in));
String text = reader.readLine();
if (text != null)
LOG.debug("Response Text: " + text);

response += "Project " + collabID + " has been added to community : " + communityID + "
";

conn.disconnect();
}
catch(Exception ex) {
response = "Exception adding project " + collabID + " to community " + communityID + ": " + ex.getMessage();
LOG.error(response, ex);
}

addOutput(new Param("collabid", "" + collabID, "output", null));
addOutput(new Param("communityid", "" + communityID, "output", null));

LOG.info("< Add Collab Project to Community: " + response);
return response;
}

You got the “To help protect your security, Internet Explorer blocked this site from downloading files to your computer” blues, huh?

I’ve tried creating a Plumtree Filter, and that worked pretty well, but not quite enough.

I’ve tried tweaking the Portal’s Javascript files, and THAT worked pretty well, but again, not quite well enough.

So, today, my friend’s, third time’s a charm:  rather than trying to fix this on the server side, we’re going to knock out this issue once and for all on the client side.  Check out those previous blog entries for a more detailed description of the problem, but basically, it’s because the portal uses a crazy convoluted way of opening documents via javascript. 

What we’re going to do today is stick some javascript in the footer of the page.  This JavaScript is going to simply find all those back-asswards links and replace them with NORMAL <a href=xxx target=_new> links.  If you add it to the footer of your site (specifically, the footer used for the KD, but the code is smart enough not to do anything if it’s on all pages), it should be able to take care of the rest.  Just make sure you add it to the Presentation Template and not the Content Item, because you-know-who only knows what a mess the out-of-the-box rich text editor is with javascript and adaptive tags.

The code after the break should be self-explanatory, but as always, if you’ve got a question or comment, feel free to post it here.  Also note that this code only fixes the download links; it doesn’t kill that “Open/Save” dialog box for things like HTML files.  For that you’ll still need the Plumtree Filter.

<pt:common.transformer pt:fixurl="off" xmlns:pt='http://www.plumtree.com/xmlschemas/ptui/'/>
<script>
try
{
       // only run in the KD
       if (document.title=="Directory")
       {
              // get all links
              var anchors = document.links;
              for (x=0; x<anchors.length; x++) {

                     // get only those with an onclick event
                     onclickJS = anchors[x].onclick;
                     if (onclickJS != null)
                     {
                           onclickJS = "" + onclickJS;
                           var locCommonOpener = onclickJS.indexOf("PTCommonOpener.openInNewWindow");
                           var locpos = onclickJS.indexOf("currentWin.location");

                           // only process links that have the broken PTCommonOpener.openInNewWindow
                           if ((locpos>=0) &amp; &amp; (locCommonOpener>=0))
                           {
                                  // extract the URL from the broken onclick function
                                  var url = onclickJS.substr(locpos);
                                  var locstart = url.indexOf("'");
                                  if (locstart>=0)
                                  {
                                         url = url.substr(locstart+1);
                                         var locend = url.indexOf("'");
                                         if (locend>=0)
                                         {
                                                // update the URL by clearing the onclick and setting the URL to open in a new window
                                                url = url.substring(0,locend);
                                                anchors[x].href=url;
                                                anchors[x].target="_new";
                                                anchors[x].onclick=null;
                                         }
                                  }
                           }
                     }
              }
       }
}
catch (err)
{
       // ignore errors
}
</script>

Ever gotten this little present after doing an upgrade to 10gR3, when trying to open a document in the Knowledge Directory using IE7 or IE8?

Ah, the old “To help protect your security, Internet Explorer blocked this site from downloading files to your computer.”  What’s even more ridiculous, if you “accept” the download, it STILL doesn’t work because IE tries to reload the page, and WCI is very stupid about how it opens this popup window (see how that address bar shows “about:blank”?).  It seems this only happens in IE, and only if you have adaptive layouts disabled with “open documents in new window” enabled, so it doesn’t affect everyone.  But I die a little on the inside every time I see that stupid thing: yes, my friends, I am an empty, hollow shell of a consultant.

Fortunately, I decided to seek redemption for WCI and myself by proxy, and checked out the HTML source for a typical file open link.  It’s kinda hilarious:

<a href="#" onclick="var currentWin = PTCommonOpener.openInNewWindow('', 'Opener_18_1322446', 800, 600, true); currentWin.location= 'http://server/portal/server.pt/document/1322446/slide_1'; return false;">Doc Name</a>

Whhaaaaaaa…!?  Sure I know there are dozens of ways you can open a document in a popup window, and many have their advantages (for example, by using JavaScript you can control the size and layout of the window), but I’d be hard-pressed to come up with a worse way to open a document.  I’ve always hated the fact that you can’t just hover over the link to see the URL, and can’t right-click and copy the shortcut to mail to someone later. (Tip: use adaptive layouts and these problems go away!).  Or they could have at least just done a window.open method in that onclick event.  OK, so they wanted to use a wrapper method – that’s fine – but the PTCommonOpener.openInNewWindow actually takes a URL paramater, so they could have just passed the URL into that function, rather than creating a new, EMPTY document and then trying to use Javascript to load the document into that window.  At very least they could have put the document URL in the “href” parameter so it’d work without JavaScript (and be 508-compliant) and users could copy the links with a simple right-click.

OK enough rambling.  On to a solution:

It’s clear looking at the above code that while Microsoft’s security controls can sometimes be oppressive, this blocked transfer kinda makes sense:  IE blocks downloads that weren’t initiated by the user (i.e., were initiated by JavaScript).  The problem is, given the brain-dead way that documents are opened in a new window (by creating an EMPTY window first, then trying to download the document later), when you accept the download, the browser reloads the about:blank() page instead of the actual file.

Using a .NET decompiler (I used dis# because I needed to search the entire portaluiinfrastructure.dll for the text string “openInNewWindow”), I found the code in com.plumtree.portaluiinfrastructure.opener.PTOpenerLinks:

public static string GetJSOpenInNewWindow(string _strURL, string _strWindowName, string _strWindowWidth, string _strWindowHeight, bool _bIsWindowFancy)
        {
            com.plumtree.openfoundation.util.XPStringBuilder sbOpenerJS = new com.plumtree.openfoundation.util.XPStringBuilder(300);
            sbOpenerJS.Append("var currentWin = ");
            sbOpenerJS.Append("PTCommonOpener.openInNewWindow");
            sbOpenerJS.Append("('', '");
            sbOpenerJS.Append(_strWindowName).Append("', ");
            sbOpenerJS.Append().Append(", ");
            sbOpenerJS.Append(_strWindowHeight).Append(", ");
            sbOpenerJS.Append(_bIsWindowFancy);_strWindowWidth
            sbOpenerJS.Append(");");
            sbOpenerJS.Append("currentWin.location=").Append(_strURL);
            return sbOpenerJS.ToString();
        }

Ideally, I’d change the code to something like this:

public static string GetJSOpenInNewWindow(string _strURL, string _strWindowName, string _strWindowWidth, string _strWindowHeight, bool _bIsWindowFancy)
        {
            com.plumtree.openfoundation.util.XPStringBuilder sbOpenerJS = new com.plumtree.openfoundation.util.XPStringBuilder(300);
            sbOpenerJS.Append("var currentWin = ");
            sbOpenerJS.Append("PTCommonOpener.openInNewWindow");
            sbOpenerJS.Append("('");
            sbOpenerJS.Append(_strURL);
            sbOpenerJS.Append("', '");
            sbOpenerJS.Append(_strWindowName).Append("', ");
            sbOpenerJS.Append().Append(", ");
            sbOpenerJS.Append(_strWindowHeight).Append(", ");
            sbOpenerJS.Append(_bIsWindowFancy);_strWindowWidth
            sbOpenerJS.Append(");");
            return sbOpenerJS.ToString();
        }

(or even better, figure out how to change this to a normal link like <a href=”http://url” target=_new>docname</a>)

… but recompiling decompiled code – especially in a .NET library as large as portaluiinfrastructure – well, that just wasn’t going to happen.

So we can’t change the HTML that generates this terrible link, but is there at least a way to fix the problem where we can get the browser to open the link in a new window in one step instead of two?  Fortunately, the answer is yes.  I’ll leave the analysis of this hack to you, but basically it creates a global object and allows both of those calls (open the window and set the URL) to be made before actually calling the open window method.

Open the PTHOME\imageserver\plumtree\portal\private\js\ptcommonopener.js file and change:

PTCommonOpener.openInNewWindow = function(_strURL, _strWindowName, _strWidth, _strHeight, _bIsFancyWindow)
{
 return PTCommonOpener.JSUTIL_VERSIONOBJ.PTWindowUtil.openWindow(_strURL, _strWindowName, _strHeight, _strWidth, _bIsFancyWindow);
}

… to:

var newwin = {location:'', _strWindowName:'', _strWidth:'', _strHeight:'', _bIsFancyWindow:''};
PTCommonOpener.handlePopup = function() {
 PTCommonOpener.JSUTIL_VERSIONOBJ.PTWindowUtil.openWindow(newwin.location, newwin._strWindowName, newwin._strHeight, newwin._strWidth, newwin._bIsFancyWindow);
}

PTCommonOpener.openInNewWindow = function(_strURL, _strWindowName, _strWidth, _strHeight, _bIsFancyWindow)
{
 if (_strURL != "")
  return PTCommonOpener.JSUTIL_VERSIONOBJ.PTWindowUtil.openWindow(_strURL, _strWindowName, _strHeight, _strWidth, _bIsFancyWindow);

 newwin.location=_strURL;
 newwin._strWindowName=_strWindowName;
 newwin._strWidth=_strWidth;
 newwin._strHeight=_strHeight;
 newwin._bIsFancyWindow=_bIsFancyWindow;
 window.setTimeout("PTCommonOpener.handlePopup();",50);
 return newwin;
}

Update 7/17/2010: Thanks to Joel Collins for helping out with some of the code here and building the solution’s binaries! Hopefully you find them useful so you can just deploy the .DLL without having to compile it yourself. Download DisplayFilter.zip for the binaries (source and config files included).

There are two main problems: poorly implemented document open handlers (which I’ll discuss in my next post), and that pesky Content-Disposition header that tries to force the browser to throw up an “Open/Save” dialog instead of just opening inline (which is definitely useful for HTML and Office files in particular, where users just want to view the documents in their browser without having to save ‘em first).  A third but ancillary issue is that occasionally the portal gets the MIME type of the document wrong in the Content-Type header, which is typically using application/octet-stream and doesn’t give the browser any clue about what type of file it is.

In the past posts I’ve described using BigIP iRules to remove the Content-Disposition header, but I ran into another client issue recently where just killing this header isn’t enough.  Take the following response headers for a document transfer that is NOT using the iRule to kill the Content-Disposition header:

This PowerPoint file, when clicked on in the portal, will throw the open/save dialog, but what if we wanted it to give the browser the option to open in-line?  We’d get rid of that Content-Disposition header.  Here’s the problem:  if we do that, the portal is returning a Content-Type of application/octet-stream.  Which means, without the file extension in Content-Disposition, the browser has no idea what type of document this is, so it throws up a “FIND PROGRAM/Save” dialog box instead of an “OPEN/Save” dialog box.

The solution to this problem would be to drop the Content-Disposition header, but use the file extension to fix the Content-Type while we’re at it (to application/vnd.ms-powerpoint).  But now our iRules are getting complicated, and not everyone has BigIP anyway.  Fortunately, my love/hate relationship with support.oracle.com shifted much more to the former when i found this: How to Eliminate the ‘Save/Open with’ Prompt when Opening HTML Files [ID 971003.1].  Then, of course, it shifted back to the latter when I realized that I found this article by complete dumb luck navigating the terrible interface, and the article is nowhere to be found searching through Google. But that’s another story.

At any rate, a solution was clear: you can write a .NET or Java FILTER to manipulate headers before they’re returned to the browser!  As such, I took the code from that article and expanded on it with a .NET filter of my own, which will:

1. Remove the Content-Disposition header selectively on different file types
2. Change the Content-Disposition header to use “inline” instead of “attachment” instead of just deleting the header (this seems to work with some browsers; a brief discussion on the differences is here)
3. Fix the Content-Type header if the file name extension doesn’t map the MIME type the portal thinks it is
4. Do all this through a filter and a dynamically loadable varpack that allows different configurations based on the type of file being served.

So while it’s a bit optimized in the sense that it only looks at responses being gatewayed through the portal, it’s still kind of a hack because personally, I think this should be an option in the portal in the first place rather than adding the additional overhead of a filter.

But, nonetheless, it seems to work well, and you can download the code here and the varPack file here.

If you’d like assistance with actually building and deploying this, or porting to Java – drop me a line.

This post is about that step where the portal transforms the HTML you return from the your custom code.  I could be incredibly long-winded here about all sorts of tricks and nuances of some adaptive tags that seem to only half-work, but figured I’d just share some quick tips to give you some ideas on how you can trick the gateway engine to do your bidding.

Solution:  The portal’s parser isn’t all that smart; it just parses the DOM and looks for items like <img src> or <a href> parameters, so if you obfuscate the link a bit, the portal won’t detect it as a “real” link: 

               document.write(‘<a hre’ + ‘f=”/portal/server.pt?open=512&objID=382″>link text</a + ‘>’); 

Solution #1: Add the variable to an object, set the object.location, and use that string so that when rendered, the transformer will wrap its transformation javascript around your code: 

                var actionServlet = new Object();

                actionServlet.location = ‘<%=SERVLET_URL%>’;

                var actionServletURL = actionServlet.location; 

Solution #2: Directly call the Javascript method available on every page to manually transform the link: 

               var actionServletURL = pt_<%=portletID%>.transformURL(‘<%=SERVLET_URL%>’); 

Solution: The portal looks at the MIME type of a document/file before it decides to parse it, and is pretty strict about only parsing MIME types with “text/*” in them (like “text/javascript”).  But browsers aren’t so strict!  So if you set the MIME type of your javascript file to “application/javascript”, the portal won’t transform it, but the browser will still run it like any other javascript file: 

               response.setHeader(“Content-Type”, “application/javascript; charset=utf-8″ );

You won’t need any of this stuff today (or tomorrow), but someday when you’re pulling your hair out and thinking to yourself “if only BEA’s CodeShare was still around!”, this is the link you’re looking for: https://aqualogic-interaction.samplecode.oracle.com/ (free registration/login required).