Websphere Portal theme navigation context menus

I spend a lot of my day working with WebSphere Portal server, and as of late, spending more time (than I’d like!) with themes & skins. I am currently working with Portal v6.1, but the information below should be useful for previous versions as well.WebSphere software Our portal is pretty open, we want people to come in & customize it as much as they’d like. One feature that we allow is for the user to come in & create new pages. We are running our own theme policy which is a copy of the DoubleTopNav policy. Our theme displays these 2 levels of navigation at the top, and we have no side navigation. The hurdle I ran into was - how do I prevent the “New Page” option from appearing in the portlet menu for pages in the second level of navigation? The way the out-of-the-box Portal theme works is that when you create a new page, it is created as a child of the page that you are on. This works fine for top level pages, but there no policy or rule that can be set to prevent the “New Page” option from appearing in the portlet menu for second level pages. The solution, proposed by a member of the Portal team was to create an alternate pageContextMenu.jsp which simply didn’t have a “New Page” option. Since the call the that JSP is done via AJAX, prior to the call we can determine what navigation level we are on and call the appropriate version of pageContextMenu.jsp. Piece of cake, right? Eh .. maybe not cake, but not all that difficult. After creating the new pageContextMenu2.jsp & removing the “New Page” option, the next place to go is head_inlineJS.jspf. Below is the code I have added/modified to the head_inlineJS.jspf.

<%-- START - see if we are in 2nd level of navigation –%>
<%
String pageContextMenuJSP = “pageContextMenu”;
%>
<portal-navigation:navigation startLevel=”2” stopLevel=”3”>
portal-navigation:navigationLoop
<portal-logic:if nodeInSelectionPath=”yes”>
<%
//it’s in selection path & it’s selected (this is the page we are on!
if (wpsSelectionModel.isNodeSelected(wpsNavNode)){
int level = wpsNavLevel.intValue();
if (level == 2) {
pageContextMenuJSP = “pageContextMenu2”;
}
}
%>



<%-- END - see if we are in 2nd level of navigation –%>

<%-- Context Menu Initialization –%>
<c-rt:set var=”pageNoActionsText” ><portal-fmt:text bundle=’nls.engine’ key=’info.emptymenu’ />
(function(){

var pageMenuURL = ‘<portal-navigation:url themeTemplate=”<%=pageContextMenuJSP%>” />’;
<%-- OLD var pageMenuURL = ‘<portal-navigation:url themeTemplate=”pageContextMenu” />’; –%>

Now that you’ve got that taken care of, touch head.jspf && touch Default.jsp, reload your page and you should no longer see “New Page” as an option in the page drop down for pages in the 2nd level of your navigation. That worked and was a thing of beauty .. well, almost. I wasn’t a big fan of looping through the entire navigation model, but I didn’t know any other way. I ran the code past my colleague from the Portal team and he pointed me at the navigationSelectionModel. The code below is smaller & faster. Best of all - it works :)

<%-- 2009.05.04 OLORE - see if we are in 2nd level of navigation –%>
<%
String pageContextMenuJSP = “pageContextMenu”;

int level_count = 0;
for (java.util.Iterator i = nsm.iterator(); i.hasNext(); ) {
NavigationNode node = (NavigationNode) i.next();
level_count++;
}
if (level_count >= 4) { // level 4 == our 2nd level of top navigation (shouldn’t ever be >)
pageContextMenuJSP = “pageContextMenu2”;
}

%>
<%-- 2009.05.04 OLORE - see if we are in 2nd level of navigation –%>

<%-- Context Menu Initialization –%>
<c-rt:set var=”pageNoActionsText” ><portal-fmt:text bundle=’nls.engine’ key=’info.emptymenu’ />
(function(){

<%-- 2009.05.01 OLORE - use pageContextMenu2 if we are in 2nd level nav –%>
var pageMenuURL = ‘<portal-navigation:url themeTemplate=”<%=pageContextMenuJSP%>” />’;
<%-- 2009.05.01 OLORE - use pageContextMenu2 if we are in 2nd level nav –%>

Launched new Twitter accounts

I was inspired by this story in the Anchorage Daily News about a woman that started @AKBadDrivers “who started describing bad drivers on her personal Twitter feed from her spot in the passenger seat as she commuted in from Wasilla.” The simple brilliance of this usage of Twitter really struck me. With tweets like

  • silver jeep, FLB 272. thanks for cutting me off not once but TWICE when you were going straight in turn only lanes prick.
  • To the girl in the Green Explorer outside Muldoon Fred Meyers this afternoon: Sorry my U-turn scared you. My bad :-(
  • white Nissan pu FEL 365 hang up ur cell phone pay attention 2 ur driving. ur lane ended & you nearly hit me merging 2 mine.

… I wanted a piece of that action! So I started @NJBadDrivers and @CTBadDrivers. Then I realized I better grab @NYBadDrivers to complete the tri-state trifecta. Imitation is the sincerest form, right ? After talking to my buddy who moved up to Alaska, he said that people really are crazy drivers up there, but come on, can they really be worse than New York, Connecticut or New Jersey drivers? (Admittedly, I’ve had licenses in all 3 states.) I’m running with Christopher Finke’s slick little python application called retweet on my Dreamhost account. If Chrstopher’s name sounds familiar (it should!) it’s cuz he’s the mastermind behind ScribeFire and the TwitterBar Firefox add-on. For those interested in running retweet on Dreamhost, be sure to use python2.5 as it already has the sqlite3 library configured. Once I figured that out, I cron’d it and it’s been working like a charm. So how’s it work? All you need to do is send a message to one of the accounts via Twitter and it will get retweeted by the bot. Just say “@NJBadDrivers does anyone around here know how to function at a four way stop???” or “@NYBadDrivers srsly people, traffic circles are not that difficult”. I wonder… is reserving Twitter names the new domain squatting? If so, would it be called twatting?