Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Corona CC Model Changes"
| Line 20: | Line 20: | ||
== Project Context Container == | == Project Context Container == | ||
| − | ''Pawel Kaczmarek'' | + | <div style="text-align: right">''Pawel Kaczmarek''</div> |
Merge PCC and CC. There are VERY few operations that are specific to ProjectContextContainer. The separation of the two causes many unnecessary packages and classes to be created and maintained. The idea behind CC and PCC was to support extensibility, however, the classes are so highly integrated within Corona that it is doubtful if anyone will want subclass CC or PCC. | Merge PCC and CC. There are VERY few operations that are specific to ProjectContextContainer. The separation of the two causes many unnecessary packages and classes to be created and maintained. The idea behind CC and PCC was to support extensibility, however, the classes are so highly integrated within Corona that it is doubtful if anyone will want subclass CC or PCC. | ||
| Line 26: | Line 26: | ||
== Content-format attribute in repository - [https://bugs.eclipse.org/bugs/show_bug.cgi?id=168680 bug 168680] == | == Content-format attribute in repository - [https://bugs.eclipse.org/bugs/show_bug.cgi?id=168680 bug 168680] == | ||
| − | ''Marcin Okraszewski'' | + | <div style="text-align: right">''Marcin Okraszewski''</div> |
All details in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=168680 the bug]. | All details in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=168680 the bug]. | ||
== Rename URI attribute to ID == | == Rename URI attribute to ID == | ||
| − | ''Marcin Okraszewski'' | + | <div style="text-align: right">''Marcin Okraszewski''</div> |
The name of URI attribute is misleading. Its primary function is ID. It is intended to keep URI form to keep uniqueness and be easily used in external RDF. But the URI suggests that it carries some kind of connection information, which it doesn't. | The name of URI attribute is misleading. Its primary function is ID. It is intended to keep URI form to keep uniqueness and be easily used in external RDF. But the URI suggests that it carries some kind of connection information, which it doesn't. | ||
== Resource id for content adapter == | == Resource id for content adapter == | ||
| − | ''Marcin Okraszewski'' | + | <div style="text-align: right">''Marcin Okraszewski''</div> |
We intend to make a layered architecture there there is repository adapter and content adapter. The content adapter would parse resource returned by repository adapter. So, the content adapter needs to know the argument to call fetchResource() with. | We intend to make a layered architecture there there is repository adapter and content adapter. The content adapter would parse resource returned by repository adapter. So, the content adapter needs to know the argument to call fetchResource() with. | ||
| Line 42: | Line 42: | ||
== Repositories as an external entity ; repository events ?? == | == Repositories as an external entity ; repository events ?? == | ||
| − | ''Marcin Okraszewski'' | + | <div style="text-align: right">''Marcin Okraszewski''</div> |
Comes from a pretty simple use case. We have a repository which is added to two containers (A and B). Now someone changes state of the repository (eg. removes a resource), but in container A. The event is sent in container A. An other user that works with container B is not aware of the change !!!!! | Comes from a pretty simple use case. We have a repository which is added to two containers (A and B). Now someone changes state of the repository (eg. removes a resource), but in container A. The event is sent in container A. An other user that works with container B is not aware of the change !!!!! | ||
| Line 48: | Line 48: | ||
== Tree structure of containers (subcontainers) - repository inheritance == | == Tree structure of containers (subcontainers) - repository inheritance == | ||
| − | ''Marcin Okraszewski'' | + | <div style="text-align: right">''Marcin Okraszewski''</div> |
At the very beginning we had an approach that containers would be organized in tree structure. Then we have changed it into "related containers". Why don't we have both? | At the very beginning we had an approach that containers would be organized in tree structure. Then we have changed it into "related containers". Why don't we have both? | ||
Revision as of 09:32, 7 March 2007
First of all I think we need to define use cases and see if we can support it with current model.
Contents
ContextContainer
The ContextContainer (and ProjectContainer) classes are generated from an EMF model. Additional methods need to be added to these classes as well as updating the functionality provided by some of the generated methods.
- Modify our usage of EMF to generate the model from annotations from the ContextContainer interface instead of schema
- Create a JET template to use by EMF/SDO code generation to merge new functionality as well as update existing methods
- ContextContainer.postEvent()
- Estabalish the only way to post a container event is by using the container's postEvent() method.
- Refactor non-container event posting mechanisms as internal.
- Annotate the postEvent() for WS-Notification
- ContextContainer.addEventHandler()
- Estabalish the only way to add a container event listener is by using the container's addEventHandler() method.
- Refactor non-container event handler mechanisms as internal.
- ContextContainer add/update/delete methods
- embed within each add/update/delete methods an invocation of postEvent() to notify the collaboration environment that the container has been modified.
- Common ProjectContainer functionality
- Refactory ProjectContainer to move any non-Project specific functionality to the ContextContainer
Project Context Container
Merge PCC and CC. There are VERY few operations that are specific to ProjectContextContainer. The separation of the two causes many unnecessary packages and classes to be created and maintained. The idea behind CC and PCC was to support extensibility, however, the classes are so highly integrated within Corona that it is doubtful if anyone will want subclass CC or PCC.
Probably it will be faster to leave PCC and merge CC into it.
Content-format attribute in repository - bug 168680
All details in the bug.
Rename URI attribute to ID
The name of URI attribute is misleading. Its primary function is ID. It is intended to keep URI form to keep uniqueness and be easily used in external RDF. But the URI suggests that it carries some kind of connection information, which it doesn't.
Resource id for content adapter
We intend to make a layered architecture there there is repository adapter and content adapter. The content adapter would parse resource returned by repository adapter. So, the content adapter needs to know the argument to call fetchResource() with.
Eg. We have a team member XML file in CVS. Repository adapter is used to connect CVS. Content adapter is used to parse the file. But how the content adapter know which file to choose?
Should it be some predefined repository connection?
Repositories as an external entity ; repository events ??
Comes from a pretty simple use case. We have a repository which is added to two containers (A and B). Now someone changes state of the repository (eg. removes a resource), but in container A. The event is sent in container A. An other user that works with container B is not aware of the change !!!!!
This leads to a point that maybe repositories should be detached from CC. CC would contain only a reference to a repository. That would mean that either we would have to provide also repository events or propagate the event in all CC that refers to repository.
Tree structure of containers (subcontainers) - repository inheritance
At the very beginning we had an approach that containers would be organized in tree structure. Then we have changed it into "related containers". Why don't we have both?
Why? Look into definition of containers for Corona project. There are a number of containers: Corona, Corona Development, Corona Client, Corona Server... Each of the containers need to contain a team member repository, which is the same for all of them. Eg. Bugzilla is similar case.
If we had a tree structure of containers and provide a new flag in repository ("inherit"), we could solve it. Note that the system container is intended to contain other repositories, so the mechanism of sub containers need to be available anyway. In this way for instance we could define a default event router for all containers at a single server.