[jboss-dev-forums] [Design of JBoss Portal] - Dashboard & Personalization proposal

Up to 2.4 versions JBoss Portal focused on shared objects, such as shared pages and portlet instances. Note that it does not mean that users are not able to personalize one instance of a portlet, it means that there is a one to one state relationship between a user and an instance. For example, the administrator creates and configures an instance XYZ of a portlet, then any (authenticated) user is able to use that portlet instance and further customize it. ---Portlets, instances and customizations The main use case we want to add is to give the possibility to users to create private pages (dashboard) and multiple customizations of pre-configured portlets. The minimum requirements are : - the portal can create on behalf of the user as many customization as they need - the portal needs to keep as minimal as possible the number of customizations - the portal keep tracks of the customizations in order to facilitate the management of the lifecycle of the state - the portal provide private pages Instance container modifications: - instead of making it implicit that a user has a customized version of an instance, make it explicit. It allows to not restrict the customization id to only the user id. The customization id can be assembled by the portal to combine the user id and any contextual information like a page id or a window id. - make the distinction between two kinds of instances which are shared and non shared (thus using the explicit customization id) - add new security permissions | // An instance of a portlet | public interface Instance | { | String getId(); | Portlet getPortlet(); | void setProperties(PropertyChange[] changes); | PropertyMap getProperties(); | void invoke(PortletInvocation invocation) | ... | } | | // A shared instance that defines a scope under which customizations can be created | public interface InstanceDefinition extends Instance | { | InstanceCustomization getCustomization(String customizationId); | } | | // An instance customized and referenced by its customization id | public interface InstanceCustomization extends Instance | { | InstanceDefinition getDefinition(); | } | The getCustomization(String customizationId) returns a lazy customization which means that no persistent state is created until the instance gets really customized. When state creation occurs on the producer side it triggers the insertion on the consumer side. examples of usage : 1. in a shared page | String instanceId = window.getInstanceRef(); // We have a shared page, get the instance definition | InstanceDefinition instanceDef = instanceContainer.getInstanceDefinition(instanceId); | Instance instance = null; | if (userId != null) | { | instance = intanceDef.getCustomization(userId); | } | else | { | instance = instanceDef; | } | 2. on a private page it is the same scenario except that the user id is an assembly of contextual information with the proper encoding | String userId = userId + "." + window.getId(); | InstanceDefinition and InstanceCustomization have a relationship in order to keep track of all customizations for a given definitions, they also have the same life cycle. When an instance is destroyed then all the customizations are in order to cleanup resources properly. In the future we will add time based expirations when our framework will support that WSRP 2.0 feature. ---Dashboard The dashboard is a private page for a specific user. At the moment we have the concept of a shared persistent tree. Dashboarding can be added by namespacing conveniently object trees (à la JNDI). examples of usage : 1. default.default points to the default page of the default portal in the default namespace which is the shared namespace 2. user:xyz.default points to the default page of the user xyz 3. webapp:foo.default.default points to the default page of the default portal of portal defined in -object.xml of foo.war Portal object modifications: - add a namespace to make the clean distinction between intended usage of objects - update the war file -object.xml mechanism to store the data tree in a specific storage (in memory) based on the web application - add new URL mappings to expose objects in a friendly manner - update security permissions - add copy / move operations between namespaces View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976377#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...