Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Corona More Generic PCC Manager"
(→Team management) |
(→ClientContext parameter) |
||
| Line 9: | Line 9: | ||
On the server side, there need to be something that would make use of the context information. And again the open() method on server side would use an extension point to detect context information consumers. It would pass it there. In project example, the project context would build map of client id to user. | On the server side, there need to be something that would make use of the context information. And again the open() method on server side would use an extension point to detect context information consumers. It would pass it there. In project example, the project context would build map of client id to user. | ||
| + | |||
| + | This could look somehow similar to this: | ||
| + | |||
| + | [[Image:Context extensions.png]] | ||
| + | |||
| + | # Someone calls open() method for a context container. | ||
| + | # The container manager proxy creates a ''client context'' object and looks for the ''context extenders'' declared in extension point. Each of them is invoked and has an ability to add its information to ''client context'' object. | ||
| + | # The open method is invoked on the server with the created ''client context'' as a parameter. | ||
| + | # The server side again looks for ''context extenders'' and passes the ''client context'' object. There should be corresponding ''context extenders'' on client and server side. The server side for instance keeps information that given client is a user. | ||
Both client and server side context consumers/fillers could implement the IContextContainerManager interface. So, they could react for any method invoked on the ContextContainerManager. | Both client and server side context consumers/fillers could implement the IContextContainerManager interface. So, they could react for any method invoked on the ContextContainerManager. | ||
Revision as of 06:11, 12 March 2007
There are two managers now - ContextContainer Manager and Project Container Manager. The difference between them is that Project one introduces methods connected with users (eg. openContainerForMember()). This causes some problems, eg. you need to distinguish whether you want to open CC or PCC.
I think we could use the more generic manager interface for Context Containers only.
ClientContext parameter
Instead of providing a methods openContainerForMember() and closeContainerForMember() we could have a generic method openContainer() which would have a parameter with client context. The client context would be a some kind of properties (name-value). By default the context contains only the client id.
Now, any new context that may want to add something would register with extension point. The project context would simply add property with the user. An other context would add whatever it wants.
On the server side, there need to be something that would make use of the context information. And again the open() method on server side would use an extension point to detect context information consumers. It would pass it there. In project example, the project context would build map of client id to user.
This could look somehow similar to this:
- Someone calls open() method for a context container.
- The container manager proxy creates a client context object and looks for the context extenders declared in extension point. Each of them is invoked and has an ability to add its information to client context object.
- The open method is invoked on the server with the created client context as a parameter.
- The server side again looks for context extenders and passes the client context object. There should be corresponding context extenders on client and server side. The server side for instance keeps information that given client is a user.
Both client and server side context consumers/fillers could implement the IContextContainerManager interface. So, they could react for any method invoked on the ContextContainerManager.
Event enhancers
As we know, the open() method sends the open event. If we do not have the open() method in project scope, the event would lack the information of the user, who opened the event. But, again with extension points, we can register event enhancers. Event enhancer would be objects that obtain event and adds some information to it, before it is published. They would be done in ContextContainerEventAdmin.sendEvent().
Again in the project context, there would be an event enhancer that sets the user connected with the event.
Team management
One more thing provided by PC Manager over CC Manager are team methods (listActiveMembers(), joinProject(), ...). This functionality can be simply moved to an additional WS endpoint that would provide such functionality. The endpoint would could be defined in container as an repository.