Using com.bowstreet.builders.webapp.api.Method

I've been writing some more custom builders recently and had a hard time figuring out how to generate a method with arguments.

Below is an example:

        Method method = new Method(builderCall, genContext);
        method.setName("myMethod");
        IXml args = null;
        
        try {
           args = XmlUtil.parseXml("<top><Argument><Name>msgValue</Name><Type>String</Type></Argument></top>");
        } catch (IOException e) {
           e.printStackTrace();
        }
        
        method.setArguments(args);
        StringBuffer sb = new StringBuffer("{ \n");
        sb.append("    webAppAccess.getVariables().getVariable(\"myVar\").setValue(msgValue); \n");
        sb.append("}");
        method.setBody(sb.toString());
        method.invokeBuilder();

and here's the code added to the model on regen:

/**
 * Generated Method [myMethod]
 */
public void myMethod(WebAppAccess webAppAccess, String msgValue)
{ 
    webAppAccess.getVariables().getVariable("myVar").setValue(msgValue); 
}

I figured out the magic XML for method.setArguments() by looking at the model XML for a standard method builder.

WEF Profiling Explained

Profiling is a frequently misunderstood concept in web experience factory. This blog entry describes profiling by comparing it to java code, something that more developers are familiar with.

Comparing Profiles to Java Code
Many people struggle with the concept of profiling and profile sets, but it can be closely compared to a conditional statement in java. Suppose that we have a button that needs to be displayed if the application is accessed from an android device. Coding this using java would look something like this (depending on the framework):

if (request.getHeader("User-Agent") == "android"){
   button.visible = true;
}

The same can be accomplished with WEF profiling except we don't have any code to work with, only a button builder with inputs. Ideally, we would want to apply the results of profiling to the builder enable input, setting it to true or false which would effectively replicate what the java code above does.

Think of a profile set as a collection of profiles and the selection of a given profile is the result of a conditional statement. That conditional statement is controlled by a selection handler. Let's look at the code above again from this perspective

if (profileset.selectionHandler.result == "android"){
   button.enable = true;
}

The profile set selection handler is the engine that controls which profile is selected. In this particular case, we're using the mobile selection handler which contains logic that looks at the HTTP request user agent header to determine which profile is selected. Moving one step further, the selection handler doesn't really return a value like "android" per se, it chooses a profile.

Suppose we not only want to control the visibility of a button, but we also want to execute a call to a service provider operation when the application is accessed from an android device. In java, we would add some logic

if (profileset.selectionHandler.profile.name == "android"){
   button.enable = true;
   invokeSomeOperation();
}

For the sake of making this explanation clearer, let's also add some code to handle iPhones as well as a handler for the default case

if (profileset.selectionHandler.profile.name == "android"){
   button.enable = true;
   invokeSomeOperation();
}
else if (profileset.selectionHandler.profile.name == "iphone"){
   button.enable = false;
   invokeSomeOperationIPhone();
}
else{
   button.enable = false;
   // do nothing
}

That all seems very obvious if we were using java, but how is it implemented in WEF using profiling?

Here is the detailed profile entry for the button

Similarly, the action list is profiled

and below is the detailed profile entry

Only one profile in any profile set can be active at one time, and profiling is applied when the user session is first initiated. It is not possible to use two different profiles from the same profile set or switch profiles in the same session.

WEF and Custom HTML

Working with custom HTML is probably one of the most common patterns I've seen when building an application with web experience factory (WEF). Typically this is a situation where I'm given a really nice HTML stub from a professional web designer and I need to build an application around it.

Don't Fight with WEF
A common mistake I see all the time is a web developer trying to untangle or intercept the code generated by WEF. Don't do it, you're going to lose your mind or create an unmaintainable mess (or both). Here are a few tips that should help:

1 - Turn off the theme
2 - Don't let the data page builder create the UI
3 - Learn how to exploit page automation

Turn off the Theme
There are two ways to accomplish this, adding a theme builder to your model and selecting the individual components, or blanking out the theme file name in the project's override.properties.

The theme is great when using WEF's default user interface, but it just gets in the way of custom HTML.

Dumb Down the Data Page Builder
The data page builder is the heart of page automation in WEF, but sometimes it wants to do too much, and again, gets in the way of custom HTML. We want dumb it down a little by turning off the option to make the UI from data.

In many cases we'll also want to set the page type to view only if we're only displaying data, but this depends on the use case.

Exploit Page Automation
Now that we've turned off some of the noise that we don't need, how do we tell the page automation to place data on our custom HTML? This is easily done by adding our own name attributes to the HTML elements. Whenever page automation finds a value for the name attribute that matches the data specified in the data page variable, it inserts a data value. Take for example the following XML data

<contacts>
   <contact>
      <name>n1</name>
      <phone>p1</phone>
   </contact>
   <contact>
      <name>n2</name>
      <phone>p2</phone>
   </contact>
</contacts>

We can ask page automation to take this custom HTML

<html>
<head>
<title>Default Test Page</title>
</head>
<body>

    <table name="contacts" width="50%">

        <tr align="center">
            <th><span name="nameHeader">Name</span></th>
            <th>Click to update</th>
            <th><span name="phoneHeader">Phone</span></th>
        </tr>

        <tr name="contact" align="center">
            <td><span name="name"></span></td>
            <td><span name="btn"></span></td>
            <td><span name="phone"></span></td>
        </tr>

    </table>

</body>
</html>

to produce a user interface, and this is what we see in the browser when we launch the application

This is how page automation sees the HTML name attributes that we added

You may have noticed that we added sorting capability to the first column, this is standard practice using a data column modifier (DCM) builder. The DCM builder needs to be able to identify the location of the table headers, and since we have custom HTML, we have to do this ourselves by adding a suffix Header to the name attribute in the table header rows.

Also note that the table row identified with the name attribute contact refers to the repeating XML data element contact. Page automation will create a new HTML row for each contact element in our data.

The edit button is there to demonstrate that we can easily add builders that refer to named locations in our HTML, just as if the data page builder had done all the work for us.

More information about manually marking up HTML for page automation can be found here.

What's in a Portal URL?

I've been working with WebSphere Portal for many years and I always wondered about the format of the URL, but never took the time to track it down. Last week I stumbled on this interesting document that laid it all out.

The short if it is that the typical URL

http://localhost:10039/wps/portal/!ut/p/b0/04_Sj9CPykssy0xPLMnMz0vMAfGjzOKd3R09TMx9DAwsTC0MDTwdPULNzYJdjAxczfXD9aPwKnE0hiowwAEcDfT9fPLT01NT_EtL9Auys9McHRUVAdjo3OY!

is an XML representation of the portal page compressed and encoded with a proprietary algorithm. It turns out there are several alternate URL schemes for WPS, but this one is the most common variation that everyone is familiar with.

No need for me to go into details - the document explains it quite well.


EDIT 09/30/2013: Here's a URL that describes REST services which will encode/decode portal URLs:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/IBM_WebSphere_Portal_Remote_State_Service_and_Fragment_Service

A Lotus Notes Calendar Widget

Most of my blog entries reflect some challenging task that I helped my client complete, this latest one was particularly interesting because there was little documentation to guide us. In fact I'm going to blog about something that I wouldn't recommend to anyone but sometimes there are no easy ways out.

The Requirement for a Calendar
My client wanted to expose their user's lotus notes calendar entries into a JSR 286 portlet but we couldn't find any easy out of the box solutions for this. Since I don't know anything (at all) about lotus domino I turned to a resident expert for advice on how to get my hands on the calendar data. We appeared to have two options:

• Develop a custom lotus form that would require replicating every user's mailbox
• Re-purpose an existing form to suit our needs

After much discussion we decided to pursue the second option since we had little time to roll out the portlet and we didn't want to alter the mailbox database of thousands of users.

Tapping into ReadViewEntries
The domino mailbox supports a URL command named ReadViewEntries that can be used to retrieve calendar entries as JSON data. The URL looks something like this

http://yourbox.com/mailServer/mailbox.nsf/Calendar?ReadViewEntries&outputformat=JSON

This request returns calendar entries for a given date range, more details can be found on this cheat sheet. Unfortunately we quickly realized that ReadViewEntries is not really designed for retrieving calendar entries formatted the way we needed. I'm not sure about the real purpose of this form, but I had to reverse engineer the results by creating a test sampling of all the different types of calendar entries (anniversary/meeting/reminder/repeated entries....) and then looking at the result set. Below is the javascript that I created to parse out the data feed

function populateCalendarData(viewentries) {

 var jqueryData = [];

 for ( var x = 0; x < viewentries.viewentry.length; x++) {
     var entry = {};
        entry.type = "meeting";

  var cday = null;
        if (viewentries.viewentry[x].entrydata[0].datetime != undefined){
            cday = viewentries.viewentry[x].entrydata[0].datetime[0];
        }
        else {
            // repeating item shows up with datetimelist
            cday = viewentries.viewentry[x].entrydata[0].datetimelist.datetime[0][0];
        }

  var sd = cday;

  // all day events don't have start dates
        if (viewentries.viewentry[x].entrydata[2].datetime != undefined){
            sd = viewentries.viewentry[x].entrydata[2].datetime[0];
        }
        else {
            entry.type = "all-day";
        }

        var ed = sd;

  if (viewentries.viewentry[x].entrydata[4].datetime != undefined){
      ed = viewentries.viewentry[x].entrydata[4].datetime[0];
  }
  else {
         // appointments don't have end dates
            entry.type = "appointment";
  }

  var startDate = getDate(sd);
  var endDate = getDate(ed);
  var moderator = "";
  var subject = "";
  var location = "";
  
  if (viewentries.viewentry[x].entrydata[5].textlist == undefined){
       // not a meeting type entry. This could be reminder or appointment
      subject = viewentries.viewentry[x].entrydata[5].text[0];
  }
  else{
      // check if a location was provided
      if (viewentries.viewentry[x].entrydata[5].textlist.text.length > 2){
          subject = viewentries.viewentry[x].entrydata[5].textlist.text[0][0];
          location = viewentries.viewentry[x].entrydata[5].textlist.text[1][0];
          moderator = viewentries.viewentry[x].entrydata[5].textlist.text[2][0];
      }
      else {
          subject = viewentries.viewentry[x].entrydata[5].textlist.text[0][0];
          moderator = viewentries.viewentry[x].entrydata[5].textlist.text[1][0];
      }
  }

  // create jquery calendar entry

  entry.date = startDate.getTime().toString();
  entry.title = subject;
  entry.description = "no description available at this time";
  entry.url = "no url";
  entry.end = endDate.getTime().toString();
  entry.location = location;
  
  jqueryData.push(entry);
 }
 
 return jqueryData;
    
}

The result is neatly populated into an array of javascript objects with the following structure

{"type":"meeting","date":"1343138400000","title":"Project A meeting","description":"no description available at this time","url":"no url","end":"1343142000000","location":"Huddle room 5"}

This data construct was then fed into a jquery widget to produce this interface

The result looks pretty good - thanks to Rick Taylor for helping me out with the lotus domino stuff.

Integrating Sametime into Portal

I recently worked with a client that wished to integrate Sametime instant messaging into WebSphere Portal. After evaluating the options available, I found that although IBM provides a Sametime portlet, it has one big drawback in that it takes so much space on the screen. User interfaces are already limited by screen size and resolution, it makes sense to use this space well.

Using a Tooltip Dialog
Most native instant messaging clients hide their user interfaces until they're needed - either to send a message or to handle an incoming message. The remainder of the time it just provides a status indicator on a tray at the bottom of the screen. This same concept can be applied to a web interface using a dojo tooltip dialog. Suppose that we've identified a location in the HTML where we want to show the Sametime status:

<div id="myClient2" onclick="ShowSTClientInFloatingPane()">Show tooltip dialog</div>

Now we can programmatically create a sametime.WebClient dojo widget using javascript:

var dsixe = {};
var tooltipDialog = null;

dojo.ready(function() {

  // Instantiate the sametime client widget
  dsixe.ST_Client = new sametime.WebClient({
      style : "width:200px;height:300px;border:1px solid black;"
  });

  dojo.require("dijit.TooltipDialog");
  
  tooltipDialog = new dijit.TooltipDialog({
    content : dsixe.ST_Client,
    onBlur : function() {
        dijit.popup.close(tooltipDialog);
    }
  });
});

and add a script to handle the onClick event that will display the Sametime buddy list:

function ShowSTClientInFloatingPane() {
   var node = dojo.byId("myClient2");
   var coords = dojo.coords("myClient2");
   var x = coords.x + 15;
   var y = coords.y + (coords.h / 2) + 5;

   dijit.popup.open({
       popup : tooltipDialog,
       x : x,
       y : y
   });

   dsixe.ST_Client.main.initLayout();
}

When we put this all together in a proper HTML page, we get something that looks like this:

Conclusion
Using this technique I was able to provide an instant messaging experience that is familiar to the end user while consuming very little screen space.

Managing CVS Branches with WEF

Today I finally had the time to resolve a problem I had experienced regarding branches on CVS with web experience factory. Sometimes I want to work with a branch that, for some unknown reason, doesn't show up in eclipse drop down lists. I know it exists, but I have no means to select it.

Eclipse and CVS Branches
The solution to the problem is documented in this eclipse CVS FAQ list, but it's worth mentioning in a WEF blog because we typically don't check in the .project file. As the FAQ explains, eclipse looks at this file to determine which branches are available for a project, so we have to change the CVS configuration to look at another file instead.

Checking in the .project file causes problems when later attempting to check out using the new WEF project wizard. Following the instructions in the FAQ above provides an easy work around.

Hope someone finds some use in this tidbit of information.