Posts Tagged ‘javascript’

Server-Side Validation – Deleting Knowledge Directory Cards

Monday, April 29th, 2013

Those of you that are familiar with the WebCenter Interaction Knowledge Directory have likely had a need to delete a batch of cards from a folder. But, if you have a lot of cards and try to delete more than 50 at a time, you’re presented with this little gem:

That’s a Javascript popup that refuses to allow you to delete more than 50 cards at a time – but what if you have 25,000 cards that you need to delete? This scenario presented itself to me recently, and I was definitely not looking forward to the prospect of deleting them 50 at a time – 500 separate deletions, which is more complicated by the fact that the Knowledge Directory shows only 20 cards at a time, so for each deletion you have to change the pagination as well.

Importantly, there is a difference between “client-side validation” and “server-side validation” – doing a check in Javascript to prevent users from doing something is completely different than doing a check on the server side for the same reason. Fortunately for me the original developers neglected to do a server-side check that would prevent the deletion of more than 50 cards. So, using the IE Developer Tools (hitting F12), I was able to add a breakpoint at this Javascript condition, and simply use the “Set next statement” option to get this method to return true:

That way, I could get the browser to submit deletion requests for 1,000 or more objects at a time.

Use this as a reminder as you develop your custom code: always confirm data entry both on the client and server sides if you don’t want users doing things they shouldn’t!

Prevent Session Timeouts

Monday, September 24th, 2012

We ran into a problem recently where one of our web applications, Frevvo, was timing out. Because Frevvo is a form building tool and we were conducting an extensive survey, occasionally users would take longer than the standard 15-minute session timeout interval. Consequently, when they submitted the survey, the web app wasn’t able to to reconcile the browser’s cookie with a server-side session, and the submission failed – resulting in a lost survey response and unhappy users.

One option was to increase the session time-out, but that could have resulted in wasted resources for users who had already closed their browser windows. Instead, we wanted users with their browser windows still open to keep their session indefinitely, while others would safely close and conserve server resources. To accomplish this, we used the following JavaScript to ensure that an HTTP request was generated from the browser to the server every 10 minutes.

The request doesn’t actually do anything, but it allows the application server to keep the session alive while the user fills out the survey. Of course, this type of script could be used for any web application that relies on sessions, and I’ve used similar scripts in the past in the Plumtree portal, where a lost session can also cause problems:

     var sessionInterval = 1000 * 60 *10; // milliseconds to minutes
       var sessionRefreshURL = "/frevvo/web/login";

       refreshFrevvoSession = function() {

              // make the request
              var xmlhttp;
              if (window.XMLHttpRequest)
                     xmlhttp=new XMLHttpRequest();  // IE7+, Firefox, Chrome, Opera, Safari
                     xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");  // code for IE6, IE5
    "GET",sessionRefreshURL+"?sessionRefresh="+new Date().getTime(),true);

              // set the timer to run again
              setTimeout (refreshFrevvoSession, sessionInterval);
       setTimeout (refreshFrevvoSession, sessionInterval); // set the initial timer

Display an “Unsupported Browser” warning in Confluence 3.4

Wednesday, November 9th, 2011

As we continue to prepare for a Post-WCI world, you’ll see this blog starting to highlight other best-of-breed products and challenges we’ve overcome with them. Today’s post is related to the fact that Atlassian’s Confluence doesn’t support Internet Explorer 9 (in version 3.4), and how we addressed it with our client.

In analyzing our logs, fewer than 5% of our roughly 5,000 users were actually using IE9. And in our testing, most of the site worked with IE9, so we didn’t want to prevent these users from accessing the majority of the site. Finally, we didn’t want to send an email or put a message on the site that didn’t apply to the other 95% of users. The solution? A piece of Javascript in the header that would display a warning to only those users accessing the site with IE9:


Bug Blog 13: Fix Broken File Downloads in 10gR3 (Part Quatre)

Tuesday, October 25th, 2011

When WebCenter Interaction 10gR3 was released, it was a complete train wreck for documents in the Knowledge Directory – the content headers were wrong, docs wouldn’t download in Internet Explorer due to the comical back-asswards Javascript file open mechanism, and links couldn’t be copied or viewed because the anchor tags were malformed.

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):

Debugging JavaScript in IE, FF, and Chrome

Thursday, October 13th, 2011

Javascript debugging can be tough – particularly when dealing with the multiple tiers that the WebCenter Interaction portal pulls code from, JS can come from different locations and get combined on one page, resulting in name collisions and other subtle problems when the portal page is rendered in the browser.

Sure would be nice to step through that JavaScript code in IE Developer or Firebug, right? Sure, you can set breakpoints in both of those tools, but what if you don’t know exactly where to set it?

Simple, just use this line in your Javascript code:


Whenever your debug window is open, this command will instruct the tool to break immediately, which will allow you to monitor variables, set other breakpoints, and step through the code. Bonus tip: whether you’re using Internet Explorer, Firebug, or Chrome, the F12 key will bring up the respective “debug window” in that environment.

One thing to keep in mind with this command is that it breaks the code immediately. So, in the above example, the breakpoint is hit before the DOM even loads. In this case, you may be scratching your head wondering why some elements in the DOM or variables in the script aren’t being displayed properly in the Watch window. That’s because if the JS or HTML comes after your breakpoint, then the browser wouldn’t have processed it from the DOM yet.

Cool Tools 21: IE Developer Tools

Friday, June 10th, 2011

At Integryst, we do a lot of Plumtree / ALUI / WCI diagnostics. We’ve featured IEWatch, IE Web Developer, and discussed FireBug as fantastic tools to diagnose what’s really going on in the portal from the perspective of the web browser.

Today’s Cool Tool is yet another one you already have but probably didn’t know it: Internet Explorer’s Developer Tools. In an IE8 or IE9 browsing session, just hit F12 to bring it up, and you’ll have virtually all of the functionality offered by those tools other tools – DOM analysis, Javascript debugging, and HTTP traffic monitoring.

Happy Debugging!

Bug Blog 12: ALUI Publisher Doesn’t Work in IE9

Wednesday, June 1st, 2011

Now that we’ve picked on Plumtree Studio for a while, let’s direct our attention back to WCI Publisher for a moment, shall we?

If you are one of the 2.9% of the general population (as of April, IE9’s first full month on the market) that use Internet Explorer 9, and also use AquaLogic Publisher – a product that dates back to the Plumtree days and is in dire need of another upgrade – you’ve no doubt noticed it no longer works in IE9:

HTTP Status 404 – /ptcs/
type Status report
message /ptcs/
description The requested resource (/ptcs/) is not available.
Apache Tomcat/5.0.30

Why? Hell if I know. Seriously, I have no idea. Publisher’s Javascript code is some of the most convoluted I’ve seen in a while.

But, all is not lost! I spent (way) too much time with Internet Explorer’s Developer Tools, comparing IE8 and IE9 URLs and stepping through Javascript on each to tease out what the difference was between the two of them. I found that when IE9 breaks, the URL doesn’t have a CID – it shows something like: site/integryst.i/gateway /PTARGS_0_200_347_0_0_43 /http%3B/localhost%3B7087 /ptcs/navigate.jsp

… instead of: site/integryst.i/gateway /PTARGS_0_200_347_0_0_43 /http%3B/localhost%3B7087 /ptcs/navigate.jsp? cid=e35977c1-2df0-417d-abd9-3c3f5f56657b&fbr=1306030533426

But, the problem seems to occur in JavaScript way before the URL is actually generated in Javascript. Specifically, I kept seeing this exception when stepping through the Publisher script:

While I don’t profess to have delved into the depths that is Publisher Javascript insanity, it was clear that this line caused the page to mis-fire and show the above error.

The fix? Open up \imageserver\imageserver\plumtree\content\private\js\hablador.js and change this:

SessionVars.prototype.toString = function() {
	return this.staticVars.toString();

… to this:

SessionVars.prototype.toString = function() {
	try {
		return this.staticVars.toString();
	catch (err) {}

That way, whatever crazy error it is that happens in this third level of hell doesn’t burn the rest of the code that generates the proper URL. Net result: Plumtree Publisher lives for another day in Internet Explorer 9.

Increase Plumtree Studio Character Limit

Monday, May 16th, 2011

We don’t write much about Aqualogic Interaction Studio ’round these here parts anymore. That’s because Studio has long since been end-of-life’d (by BEA, even before the Oracle acquisition!). But, that doesn’t mean it isn’t alive and gasping its last breath in many of your portal sites. Sure, it’s an over-the-hill product but it does serve a functional need: the ability to easily create forms, polls, and other data entry forms.

So, it’s with reluctant enthusiasm that I start the first of a three-part series on “How to increase the 1,000 character limit in Plumtree Studio”. Even if you don’t actually use Studio, hopefully you’ll find the journey interesting and informative for your other portal diagnostic needs. I’ll walk you through the process of identifying the code here, recompiling and reintegrating in Part dos, then some SQL Server diagnostics in Part tres.

The problem, as recently presented by a client, was that Studio has a 1,000 character limit on text fields. If an end user tries to type more than 1,000 characters, they get this lovely message:

But, we needed to increase that value. While it would be really nice if there was just some configuration file somewhere, sadly, the 1,000 character limit is hard-coded. So we first need to find the file that’s producing this alert. (more…)

Collab Office Tools – “Don’t Show Again”

Monday, February 7th, 2011

When working on self-signing the Plumtree Collaboration WebEdit applet to prevent the certificate warning, I had to install WCI Collaboration Server on my server.  As I usually do, I made a backup of the collab folder, ran the install, and used Beyond Compare to diff the results.  Interestingly, I found this little gem in the collab.war file in /docman/editor/officeToolsInstall.jsp:

Wha-?  Why would 10.3 have a cookie expire on 1/1/2020, and have the same cookie expire on 1/1/2010?  Who knows, but what it likely means is that te “Do not show this again” checkbox in the Collaboration Office Tools popup will never work, because it’s setting a cookie that’s perpetually expired.

The solution?  Install that Collaboration Server IE8 Critical Fix, or just crack open the .war file and update /docman/editor/officeToolsInstall.jsp to use 2020 for the cookie expiration date.

Bug Blog 6: Fix Broken File Downloads in 10gR3 (Part Trois)

Sunday, June 20th, 2010

*sigh*.  You’ve upgraded from ALUI to WCI 10gR3, and your Knowledge Directory links got all screwed up, didn’t they?  HTML files now throw an open/save dialog, some documents don’t open, you can’t copy links by just right-clicking them and choosing “Copy Shortcut”, and IE throws a popup blocker when you click a link in the Knowledge Directory, doesn’t it? 

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. (more…)