Browse Prior Art Database

Dynamic Target Determination for Modifications in Complex Page Layouts of Customizable Portal Pages

IP.com Disclosure Number: IPCOM000024532D
Original Publication Date: 2004-Apr-02
Included in the Prior Art Database: 2004-Apr-02
Document File: 4 page(s) / 165K

Publishing Venue

IBM

Abstract

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.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 4

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.

Portal Page

Row

Row

Column

Image

Column

Portlet

Portlet

Column

Column

Image

Portlet

Portlet

[This page contains 1 picture or other non-text object]

Page 2 of 4

    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...