Month: July 2014

Liferay Layout Templates finally approved!

Today our Liferay Layout Templates were finally approved. While Liferay Marketplace team took a little bit of time to finally approve them we are grateful that they finally did. Although the templates are not highly original they still fill the void when someone is missing a 15/85 or 25/75 or 40/60 ratio 2 column basic template.

While we don’t actually want to charge money for them, they did took us a small amount of time to make and getting them approved on Liferay Marketplace took also a considerable time considering all the somewhat awkward bumps we met on the road.

Basic 25 / 75 ratio layout

75-25
25-75

15/85 and 85/15 Basic layout for extra thin portlets

85-15
60-40
40-60
15-85

Liferay Birthday List portlet

cake

Just wanted to let you guys know that our very basic version of Liferay Birthday List portlet is now available for FREE on Liferay Marketplace.

You can download and install it straight from the Marketplace.
liferay birthday list portlet

The portlet relies on the Liferay’s internal user database and displays the birthdays of Yesterdays, Todays and Tomorrows birthdays.

Can’t really say that’s an achievement, but at least it’s our first Portlet on the Marketplace.
We plan to start publishing many useful Portlets to make the Liferay Ecosystem a little bit friendlier to people who don’t have development teams just hanging around, waiting for work…

We will probably publish a more feature-rich Liferay Birthday List portlet that would also show Work Anniversaries and allow sending quick Congratulations using Liferay Notifications.

dijit.Tree and Sorting

Today I want to talk about the Dojo Toolkit 1.6 version dijit.Tree and Sorting feature.
This will be a very very short tutorial on how to make it work. I recently had to make it work on an already existing application that had a few years old version of Dojo installed. Although looking at the documentation then it doesn’t seem like the new version is much better in this particular area.

dijit.tree

To get the sorting working nicely you need 3 main components: store, model and the tree. Here’s my examples on those. I’ll be using an ItemFileWriteStore to get my tree data with Ajax query to in a JSON format. We then need a TreeStoreModel that basically is just a wrapper for our tree nodes.

var myStore = new dojo.data.ItemFileWriteStore({url:"/datasource.php?format=json"});
var treeModel = new dijit.tree.TreeStoreModel({store:myStore,query:{id: "0"}});
var myTree = new dijit.Tree({
    id: 'myTree',
    model: treeModel,
    labelAttrs: "label",
    betweenThreshold: "8",
    dndController: dijit.tree.dndSource,
    checkAcceptance: dragAccept,
    checkItemAcceptance: dropAccept
}).placeAt('treeDiv');

By now you should have a working dijit.Tree with sorting functions, but no actual storage is happening yet. We’ll get to that in a second. My personal show-stopper was the fact that I tried to use dijit.tree.ForestStoreModel initially which is wrong. No matter how hard I tried – the tree just didn’t allowed sorting nodes with it.

Also, special note on the “betweenThreshold” flag – You need this property(nr of pixels) to tell the tree that the pages can be sorted within it’s current parent, not only dragged between parents. If you don’t have betweenThreshold then Dojo Toolkit 1.6 will not allow you to sort within your current parent.

So far so good. Now you might have noticed I defined dragAccept and dropAccept methods as checkAcceptance and checkItemAcceptance. You can add custom logic to those methods to define what items can be dragged to what parent nodes. This allows you to make some items incompatible with others and can prevent you from mixing Apples with Oranges in your tree. For the purpose of this tutorial we keep them VERY simple and allow sorting between all nodes. This is probably the typical case:

function dragAccept(source,nodes){ return true; }
function dropAccept(target,source,position) { return true; }

In order to store the new sorting order after you release the item from dragging you need a method to save it to the server. You could do it by saving the whole order of the whole tree into array of inputs or some other hack, but I chose the option of sending an ajax POST request on each sorting action. This means every time we release an item we will send a background POST request to the server. This means we don’t need a special SAVE button in the end of our tree. Do achieve that we have to connect to the onPaste method of the treeModel.

If we want to allow modifications to our data via drag-n-drop, we can implement the pasteItem() method and set the drag-n-drop controller for the tree.

dojo.connect(treeModel, 'pasteItem', function(childItem, oldParentItem, newParentItem, bCopy, insertIndex) {
    entityID = childItem.id[0]; // The node that was sorted
    parentID = newParentItem.id[0]; // The new(could be the old one) parent of the node
    order = 0; // We set the order to 0 first
    if (insertIndex != undefined) { // And only override it when the order is defined.
        order = insertIndex;
    }
    // Send POST to server side.
    dojo.xhrPost({
        url: "/saveorder.php?id="+entityID+"&parent="+parentID+"&order="+order,
        load: function(data, ioargs) {
            // Notify user about successful save here.
            alert('Your order was saved!');
        }
    });
});

That’s IT! You should be done now from the javascript side. The server and JSON parts should be easy as the internet is full of documentation on those. If you are using a PHP backend then it’s just a matter of using json_encode method and reading some $_POST params.

Some more reference material can be found here: http://dojotoolkit.org/documentation/tutorials/1.6/store_driven_tree/

If you have a question or having trouble getting it working then feel free to write a comment and I’ll do my best to help you out. If you would like to read more about Dojo Toolkit related subjects then also make sure to comment on that!

DB2 Backup using TSM

In this example we are using a DB2 database called WPSDB. At one point I needed to automate a backup from DB2 into Tivoli Storage Manager. IBM Tivoli Storage Manager is a data backup platform that gives enterprises a single point of control and administration for storage management needs.

Get current config:

db2 => connect to WPSDB
db2 => GET DATABASE CONFIGURATION

There will be a big long list and you are trying to find LOGARCHMETH1.

First log archive method (LOGARCHMETH1) = OFF
Options for logarchmeth1 (LOGARCHOPT1) =
Second log archive method (LOGARCHMETH2) = OFF

Now let’s change this into TSM:

db2 => update db cfg using LOGARCHMETH1 TSM
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
SQL1363W One or more of the parameters submitted for immediate modification
were not changed dynamically. For these configuration parameters, all
applications must disconnect from this database before the changes become
effective.

At this point ignore warning messages.
Let’s look if the change was OK:

db2 => GET DATABASE CONFIGURATION FOR WPSDB

First log archive method (LOGARCHMETH1) = TSM
Options for logarchmeth1 (LOGARCHOPT1) =
Second log archive method (LOGARCHMETH2) = OFF
Options for logarchmeth2 (LOGARCHOPT2) =
Failover log archive path (FAILARCHPATH) =
Number of log archive retries on error (NUMARCHRETRY) = 5
Log archive retry Delay (secs) (ARCHRETRYDELAY) = 20
Vendor options (VENDOROPT) =

Look for “First log archive method (LOGARCHMETH1)” parameter. It should now be set to “TSM”.

Restart DB2 instance:

db2 force applications all
db2 terminate
db2stop

Start DB/2

db2start

Run full DB2 backup manually as administrator:

db2 backup db WPSDB use tsm
Backup successful. The timestamp for this backup image is : 20140411144830

Proceed with enabling automated DB2 TSM backup by creating a administrative schedule that call the script (db2backup_full.cmd). You can then schedule this backup from TSM:

set DB2INSTANCE=DB2
"C:\IBM\ProductName\db2\BIN\db2cmd.exe" /c DB2.EXE backup db WPSDB user <DOMAINUSERNAME> using <DOMAINUSERPASSWORD> online use tsm include logs

So there you go, we now have a DB2 backup using TSM and it’s working automatically.

Parameterized JUnit test

Today I needed to do a quick test for a custom NameUtils class that capitalized human and business names based on some very specific rules. To do that I decided that the best way is to use a Parameterized JUnit test and the best and fastest way of doing it is by using Junit with JUnitParams. This project adds a new runner to JUnit and provides much easier and readable parameterized tests for JUnit >=4.6. According to their own JUnitParams homepage the main differences to standard JUnit Parameterized runner are:

  • more explicit – params are in test method params, not class fields
  • less code – you don’t need a constructor to set up parameters
  • you can mix parameterised with non-parameterised methods in one class
  • params can be passed as a CSV string or from a parameters provider class
  • parameters provider class can have as many parameters providing methods as you want, so that you can group different cases
  • you can have a test method that provides parameters (no external classes or statics anymore)
  • you can see actual parameter values in your IDE (in JUnit’s Prameterized it’s only consecutive numbers of parameters)

So first, since we are using maven, then we need our dependencies:


<dependency>
	<groupId>junit</groupId>
	<artifactId>junit</artifactId>
	<version>4.11</version>
	<scope>test</scope>
</dependency>
<dependency>
	<groupId>pl.pragmatists</groupId>
	<artifactId>JUnitParams</artifactId>
	<version>1.0.2</version>
	<scope>test</scope>
</dependency>


While JUnit is very common, JunitParams is probably not so popular yet. It’s a package of small helper annotations that allow you to better write your tests.

So now – what are these parametrized tests I’m talking about? Here’s a quick example:

import static org.junit.Assert.assertEquals;
import junitparams.FileParameters;
import junitparams.JUnitParamsRunner;

import org.junit.Test;
import org.junit.runner.RunWith;

@RunWith(JUnitParamsRunner.class)
public class NameUtilsTest {

	@Test
	@FileParameters("src/test/resources/NameUtils.test.csv")
	public void testNameCapitalization(String input, String expected) {
		
		assertEquals(expected, NameUtils.capitalize(input));
		
	}

}

This test asserts that our NameUtils.capitalize method returns expected results.
As you can see, we use @RunWith that tells JUnit to this test using JUnitParamsRunner and then we use @FileParameters that tells junit to run this test once for every single line in that CSV file.

On each of the CSV file lines we have our input and expected output, like this:

john doe, 					John Doe
DR. JOHN DOE, 				Dr. John Doe
ACME Corporation Ltd.,		Acme Corporation Ltd.
Miriam Torrence, 			Miriam Torrence
Shawanna Melody, 			Shawanna Melody
    SPACE     Tuma, 		Space Tuma
Jeraldine Ownbey, 			Jeraldine Ownbey
Nilda Cavaliere, 			Nilda Cavaliere
bUffy Yearta, 				Buffy Yearta,
AMANDA skoog, 				Amanda Skoog
a,							A
a b			, 				A B
Elias johnny cash Rash,		Elias Johnny Cash Rash

And now when we run our code, we get:
parameterized junit test results

Note that the test was ran for every single line in that CSV file and this allows you to quickly add new cases or testing material to constantly improve your code verifications.

If you have a question or having trouble getting it to work on your machine then feel free to write in the comment section and I’ll do my best to help you out. If you would like to read more about Unit Testing related subjects then also make sure to comment on that and if you liked what you read then make sure to subscribe – It’s FREE!