Page 3 of 3   « previous page

Layout and Hierarchy
A bean that's useful for manipulating the layout of the content-nodes is the Layout bean (rather well named, I think). With the Layout bean, we can use the index path to manipulate our content-nodes. The Layout bean has several methods (that can be seen by executing $Layout help). One such method is 'move.'

$Layout move to 0

This command would move the currently selected content-node to the root position.

$Layout move by 1

This command would move the currently selected content-node 1 level down the tree. By extension, moving by -1 would move the node up the tree one notch. This could be useful if you didn't have a lot of nested pages and whatnot under the currently selected content-node. In the event that you had an incredibly complex content-node tree, you could use another of the Layout bean's methods to transfer the currently selected content-node and all of its children to another parent:

$Layout transfer <node id> to
<new parent node id>

In our page structure example, let's pretend that we got our uid values for the WorkPlace content-node (_6_00KJL57F9D04K630_A) and the Home content-node (_6_00KJL57F9D04K219_C)

$Layout transfer _6_
00KJL57F9D04K630_A to _6_
00KJL57F9D04K219_C

Once we completed this command, our new page structure would look like this:

	Content Root
		My Portal
			Home
			WorkPlace
				Email
				Docs
			Corporate Directory

$Layout select _6_
00KJL57F9D04K219_C
$Layout adopt _6_
00KJL57F9D04K630_A

By first "selecting" the node we wish to have perform the adoption, we can then instruct it to do so. Very cool.

And now for something about the composition of these content-nodes that we're adopting and transferring all over the place. These content-nodes are comprised of rows and columns that together are called containers. Inside these containers we find our portlets that are known as controls.

The Layout bean can be used on both the containers and controls of a content-node.

Issuing the command below will give you the index paths of the potentially very complex layout of containers and controls on a page:

$Layout index

Appending a uid will give you the absolute index path of that object:

$Layout index <id>

If I start off with a blank page that I've created using the Content bean, I would definitely want to use the Layout bean to create horizontal or vertical containers (rows or columns) and controls (portlets) in those containers. If we were to use the CorpDir page as an example:

$Content select _6_
00KJL57F9D04J770_D
$Layout create container
horizontal select
$Layout create control <uid of portlet to add>

This sequence selects the content-node we want to add the portlet to. It then creates a new row on the page and selects it. The last step is to add the portlet to that row.

If we decided later to add some other portlet to this page, we wouldn't want to have to delete the whole thing and re-create it. So in that case we could simply add to our page:

$Content select _6_00KJL57F9D04J770_D
$Layout index /0 select
$Layout create control
<some_portlet_id>

This sequence selects the CorpDir page by its ID. Next we select the /0 index path of the selected object. This will return us the parent container of the page (row or column we don't much care, as long as it is the top level object on the page). Lastly we add a new portlet by using its ID.

And Onward...
There are other beans that can be used to impact our portal configuration. We can use the Access bean to read in permissions or the PacList bean to assign them to various objects. And while I reviewed the major beans that one would use to administer the configuration of the portal, my comments are by no means exhaustive.

As with all things WebSphere-related, the proof is really in the hands-on tinkering. Go install WPS5.1 and play around with the Portal Scripting Interface. Before long you'll be doing more advanced tasks such as creating entire JACL scripts composed of many actions and reading them all in at once.

This interface is new. It currently has some limitations. But the direction is pretty clear. In future releases expect the PSI to increase in importance as new functions and beans are added and expanded. In fact, I would expect PSI to supplant XMLAccess as the primary automated administration interface.

There's some information in the WPS 5.1 InfoCenter regarding this new tool. It's currently located at: http://publib.boulder.ibm.com/infocenter/ wp51help/index.jsp?topic=/com.ibm.wp.ent.doc/wps/ad_psi.html.

Page 3 of 3   « previous page