Charon Skinnable Portal

Features

• All rendering performed in an abstracted rendering engine, currently Velocity Based
• URL Mapping performed by PortalHandlers!PortletRender.png!
• Central Portal Service used as a Registry and Controller for all portals
• JSR-168 support using Pluto 1.1

The Portal is a rewrite of the Charon portal in 2.2 and 2.3. All the markup has been extracted and placed in velocity templates outside the core portal. The URL space of the portal has been abstracted and is managed/claimed by PortalHandlers which are registered with the portal at runtime via the portal service. The Tool Rendering has been added to by including a JSR-168 Container (Pluto 1.1) inside the portal so that Portlets may be dropped into Sakai and they automatically register and appear at runtime with as Tools.

Portal Context

The Portal Context represents a container for storing references to render engines (potentiall more than one per context) and PortalHandlers (more than one) associated with a single Portal. The Portal quieries the PortalService for items in the portal context.

Core Portal

The portal operates by building a view tree, represented in a PortalRenderContext and then passing that render context to a render engine which converts it into a stream sent back as the request. The implementation of the PortalRenderContext and the PortalRenderEngine are bound together, and are injected into the portletContext which is the primary container for the Portal instance.

URL Space and building the PortalRenderContext.

The URL Space is manged by PortalHandler implementations that are registered with the PortalService against a PortalContext at runtime. The Portal that binds to that PortalContext will lookup and then consult the PortalHandlers to build the PortalRenderContext. For URLS that are performance sensitive, there is a one to one mapping between the PortalHandler and a fragment of the URL Space (at present the word after /portal/ ). For less performance sensitive URLs' there can be a consultitive match where each PortalHandler is questioned in turn if they accept responsibility for the request.

Once one PortalHandler has accepted responsibility for the request is may elect to allow others to build more of the PortalRenderContext or it may elect to abort and render.

Rendering

The PortalHandler gets a RenderEngine implimetnation from the PortalService based on the PortalContext and the request object. It is down to the implimentation of the PortalService which RenderEngine is selected, but currently there is a 1:1 mapping between the PortalContext and the RenderEngine. THe PortalRenderContext is passed to the render Engine and the rendered output is sent as the response. The is currently HTML, but could be anything else.

Tool

Where a Tool placement is part of the rendered output, the ToolRenderService is invokect ot render the tool. In the Case of an Iframe tool this will the iframe tag with the suitable document location. Witha Portlet Tool, a Portlet Render is use.

Portlets

As part of the tender cycle, where portlets are involved, the portlets are first actioned, and then the portlets are rendered into a buffered render result. As with the IFrame Tool, the rendered result is placed in the PortalRenderContext and rendered by the render engine. by placing in the output stream.

What works

• JSR-168 portlets auto register and render, 3 on a screen work with posting and maintaining state.
• The standard Pluto Test Suites all work.
• Normal Charon operation all works
• Injecting Render engines and Portal Handlers all works
• Reloading any of the webapps all works

TODO:

There are no controls on portets, once minimized you cant maximize
In some curcumstances the Title of a Portlet gets lots.
THere are some velocity strings that are missing, reported in the logs.