Status

Spec writing, no implementation yet planned.

Owner

Julien Viet

Description

The Model Object for Portal (MOP) was introduced in GateIn 3.0 and remained stable for the life time of the major version of the project. It evolved thanks to the addition of mixins that allowed to make the model evolve without needed to alterate it.

Nevertheless there are a few oddities to correct that were found during the usage of the MOP. Those oddities are not blocking issues however the must be addressed in the next major version of the project.

There are two main issues found so far in the model:

• Application registry has a schema to improve
• Generic properties are not done correctly or could be removed

Solution

Application registry

The application registry provides a categorization of applications. Application exist by themselves as customization (i.e an association of state and an bare application) in the MOP at different places. In the case of application registry we consider the customization at the workspace level (i.e under the /production/mop:workspace/mop:customizations path).

In order to use them in the portal we must data on top of it for various concerns:

• describe the application : display name and description
• security : add permission on an application
• tagging (categories)

Application also exist in the application registry to implement the various concerns described above under the path /production/app:applications/category/application . Each application in this context is an implicit pointer to a customization in the mop workspace based on the application name. For instance the /production/app:applications/app:Gadgets/app:Todo points to the /production/mop:workspace/mop:customizations/mop:Todo because it has the same name (and only because of that).

This is an issue because the same application appearing in the registry can be configured several times which leads to:

• make the registry less usable : the same application description must be entered several times, it can be error prone
• be a security issue : the same application can be configured several times with different settings

Generic attributes

The MOP has an interesting way to add generic properties, this was done initially has a detyped manner to add data on an existing entity. While this is interesting this way is not really used, because it is more powerful to use mixins. Also the current implementation of properties is over engineered because it uses too much data and make unnecessary node loading.

We should look at removing generic properties in favor of mixin or make the implementation of generic properties more lightweight and instead use JCR properties instead of JCR nodes.

Note that the JCR node was chosen because we wanted to add metadata over the property, basically the use case is to control the inheriance of a property for instance: 'add a property foo=3 that is inherited in the hierarchy' or 'add a property foo=4 that is only for this node and not inherited'.

It appears that it could be possible to do the same by using a custom JCR namespace that would have the inherited corresponding value in that namespace, for instance:

- property:foo : 3

- inheritance:foo : true

this convention would provide more lightweight way for doing it than the current mechanism.

Specification

Todo