Dynamic Target Determination for Modifications in Complex Page Layouts of Customizable Portal Pages
Original Publication Date: 2004-Apr-02
Included in the Prior Art Database: 2004-Apr-02
A portal page is a hierarchically structured tree of containers (which define layout) and controls (which define content in form of portlets). It can be customizable in respect to modifications of layout and content. Modifications are actions that change the position or order of containers or controls in the tree of the page. This article presents an algorithm that dynamically determines targets for such actions.
Dynamic Target Determination for Modifications in Complex Page Layouts of
Customizable Portal Pages
Overview of the idea
Page layout structures in today's portal solutions can be quite complex. Customization of such layout structures is in general performed through the creation, deletion and movement of layout components . Movement is the more complex of those tasks as targets for the movement action have to be determined . Especially, if administrators lock certain areas of a page to make them unmodifiable to users, a user's choice is reduced to the modifiable parts of the page . So the user has to be aware of the overall structure and the locks set on the page . The idea is to have a generic target determination algorithm that takes the overall structure as well as the user permission's into account to offer movement actions for layout components in a WYSIWYG ('what you see is what you get') fashion. The user can just use a portal page that is rendered in a normal way and move objects around while the algorithm automatically calculates the possible movements as well as the best matching targets.
Background and 'state of the art'
Right now, portal server pages are based on a table layout per default due to the restrictions of markup and browser capabilities. So layout can be specified through an arbitrary structure of rows and columns that contain other layout components. This structure can be viewed as a tree of layout components with objects like rows and columns (so-called containers) as tree nodes and content -
e.g. portlets, images, etc. - as leaf nodes:
Movement of layout components within the page is usually only possible in two special ways:
1. Movement within the same parent container
E.g. in a row container, portlets can be moved left and right within this container. In a column container, portlets can be moved up and down within the container. In those cases, movement takes place within the specific parent container and does not exceed the parent container's boundaries.
2. Movement to a direct neighbor container in simple layouts If a page only consists of three column containers (A, B, and C), movement of a portlet to the direct neighbor is possible. For example, portlets from container A can be moved to container B, and portlets from container B can be moved to container C.
In more complex layouts - T-shape structures, deep and different nesting of rows and columns - no direct movement of components is offered right now . For example, if the page consists of more than just three columns which are displayed next to each other, no algorithm exists that calculates the destination of a movement.
Moreover, if an administrator locks the neighbor container, meaning no portlet or container can be moved into this container, a movement in o...