The presentation framework abstract the portal server from the client side. The portal server and the client side use that intermediary layer to exchange data and perform UI oriented interactions.  The value is the abstraction of the portal framework from the underlying client side technology (HTTP, Ajax). Therefore for the portal it is possible to have several types of clients technologies that can use the portal. For now the planned implementations are the "classic" which is the traditional request/response over HTTP and the "ajax" implementation that leverages Ajax technology (through GWT). It could be possible to develop other implementations for other presentation technologies such as Flash or Swing, it could also be possible to develop implementation more targeted for a specific device such as mobile devices.

The presentation framework requirements:

• UI oriented rather than markup oriented

• Several client side implementations must be possible

• End user client side is heterogeneous no matter what

• Need to avoid client side technology lock in

• Developing a new client side implementation must be relatively cheap

• Classic full page aggregation

• Ajax using GWT

• Ajax using a JavaScript framework

-

High level architecture:

• Definition of presentation server: the presentation server provides access to the UI environment

• Definition of presentation client: the presentation client exposes the UI concepts provided by the server and is able to perform UI interactions of various nature

It is important to have in mind that the notion of presentation client do not necessarily means that its logic is always located on the physical user agent interracting with the physical server. In the full page aggregation mode, most of the presentation client will be physically located on the server as this mode has no logic on the user agent.

The presentation server and the presentation client uses a protocol to communicate and exchange data. The protocol is always initiated by the presentation client and is uni directional from the client to the presentation server. The goal of the protocol is to decouple the presentation client and the presentation server. It will also help to test both parties in isolation.

-

Implementation:

The presentation server should be implemented close to the actual core controller.

The presentation client for full page aggregation will be located also the the server and will talk directly to the presentation server.

The presentation client using ajax will have part of its logic located on the user agent and the other part on the server.

-

Design Ideas:

• The current framework consists of hierarchial markup regions consisting of Page/Region/Window/Portlet concepts

• The Core Controller needs to be a UI agnostic component that is responsible for extracting the Portlet output. But it should not concern itself with the client to which this will be eventually rendered, layout, theme etc etc. The UI Server should handle those tasks

• There needs to be a well-designed protocol for communication between the Core Controller and the UI Server

• Between the Core Controller and the UI Server different aggregation methods such as full aggregation mode or partial aggregation mode should be handled

-

UI Server Model:

• UI Server needs to add more UI entities to the existing concepts of Page/Region/Window/Portlet.

• One such possibility is the concept of a UI component(s) rendered inside of a Portlet like Ajax components etc and managing these interactions with the Portal

-

UI Server/Core Controller Protocol:

-

Client Usecases to Prototype/Discuss