Evil Overlord 101

Monday, January 21, 2008

And now for something completely different. My son got me a game for the Xbox 360 called Overlord, the game puts the fantasy genre on its head by putting you in the role of the evil Overlord leading your army of minions to world domination. Overall a fun game that fulfills a long standing ambition of mine that my wife is continually, and successfully, thwarting. I was searching for some tips for this game when I stumbled across this site, How To Be A Successful Evil Overlord. However instead of tips for the game, it has 100 tips on avoiding the classic blunders an evil Overlord can make.

As a software developer or member of an IT staff you never know what sort of project you will be undertaking so I've extracted the IT related tips for those of you who might end up working for Hank Scorpio.

50. My main computers will have their own special operating system that will be completely incompatible with standard IBM and Macintosh powerbooks.

59. I will never build a sentient computer smarter than I am.

60. My five-year-old child advisor will also be asked to decipher any code I am thinking of using. If he breaks the code in under 30 seconds, it will not be used. Note: This also applies to passwords.

65. If I must have a computer system with publicly available terminals, the maps they display will have a room clearly marked as the Main Control Room. That room will be the Execution Chamber. The actual main control room will be marked as Sewage Overflow Containment.

74. When I create a multimedia presentation of my plan designed so that my five-year-old advisor can easily understand the details, I will not label the disk "Project Overlord" and leave it lying on top of my desk.

99. Any data files of crucial importance will be padded to 1.45Mb.

100. Finally, to keep my subjects permanently locked in a mindless trance, I will provide each of them with free, unlimited internet access.

I would recommend reading the full list if you are thinking of making a career change from software developer to evil Overlord to avoid the mistakes of your predecessors. I particularly enjoyed this non-IT related one:

81. If I am fighting with the hero atop a moving platform, have disarmed him, and am about to finish him off and he glances behind me and drops flat, I too will drop flat instead of quizzically turning around to find out what he saw.

Posted by Gerald Nunn at 4:01 PM | Categories: Other | Permalink |

Delivering Data from Portal Events to Page Flows

Friday, January 11, 2008

If you are working on a portlet project you likely will be familiar with inter-portlet communication (IPC) and Java Page Flows (JPFs). When creating IPC events, one option that is available is to invoke a JPF action in response to the event. One question that often arises though is how do you deliver data to that action?

For example, let's say you have an e-commerce portal and you have a portlet that displays an individual product. This portlet has an event that can be invoked by other portlets to display a selected product and the event that is fired contains a payload that holds the product name. So now the JPF action that is being invoked needs to get that product name in order to process it. A traditional way of doing this is to have a backing file unpack the payload and store it in the request or session where it can be retrieved by the JPF action. I've done it this way myself many times, but Nathan Lipke, one of our Portal engineers, pointed out an alternative way to handle this scenario.

It is not well documented, but if the event payload object extends the org.apache.struts.action.ActionForm object it can be delivered directly to the JPF action method without requiring the use of an intermediate backing file. Let's look at an example to make this clearer.

Using our previous example of selecting a product, here is a payload object that we define to allow one portlet to pass the selected product to another object.

public class ProductBean extends ActionForm implements Serializable {

    private String product;

    public ProductBean() {

    }

    public ProductBean(String product) {
        this.product = product;
    }

    public String getProduct() {
        return product;
    }

    public void setProduct(String product) {
        this.product = product;
    }

    @Override
    public String toString() {
        return super.toString()+"["+product+"]";
    }
}

Now we need to define an action in the JPF in our portlet to be notified when the event is fired as follows.

@Jpf.Action(forwards = { @Jpf.Forward(name = "success", path = "product.jsp") })
public Forward displayProduct(ProductBean bean) {
    this.product = bean.getProduct();
    return new Forward("success");
}

In the portlet itself, create an event handler as normal and add the invoke page flow action to the handler specifying the displayProduct action we created previously. Here is an example of how the XML would look in the .portlet file.

<netuix:handleCustomEvent event="displayProductEvent"
	eventLabel="handleDisplayProductEvent" fromSelfInstanceOnly="false"
	onlyIfDisplayed="false">
	<netuix:invokePageFlowAction action="displayProduct" />
</netuix:handleCustomEvent>

Finally in the other portlet we need to fire the event using the PortletBackingContext as follows:

PortletBackingContext pbc = PortletBackingContext.getPortletBackingContext(getRequest());
pbc.fireCustomEvent("displayProductEvent", new ProductBean(selectedProduct));

That's basically it, as mentioned previously the key to making this work is having the event payload extend the ActionForm object. Thanks again to Nathan Lipke for pointing this out to me.

Posted by Gerald Nunn at 4:01 PM | Categories: | Permalink |