Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: none, it's an enhancement More information: Currently you use the CDO editor by creating a session to a server in the CDO view. The CDO view is perfect in development setups. It does not fit customer installations. In these situation you'd like to have to set a server once in the preferences. Furthermore a customer want's to have sessions and transactions handled in a transparent manner
Good idea! I already thought about providing a client side CDORepository abstraction for a server side IRepository. This would work in the direction you proposed. For sessions and transactions (or views or audits) I propose to add two things: a) Registries for both CDOSession and CDOView (includes CDOTransaction and CDOAudit) that are able to map a String ID to an instance. b) Extension points for both CDOSession and CDOView (CDOTransaction and CDOAudit might need separate extension points) that are able to instantiate identifiable instances and register them with the registries (a).
sounds good. Just make sure I understand you right: the cdo server/transaction preferences view would trigger the registries to create corresponding instances. What UI would you suggest to feed these to the CDOEditor? Preinstantiate it in the CDO view when that one is started? (In reply to comment #1) > Good idea! > > I already thought about providing a client side CDORepository abstraction for a > server side IRepository. This would work in the direction you proposed. > > For sessions and transactions (or views or audits) I propose to add two things: > > a) Registries for both CDOSession and CDOView (includes CDOTransaction and > CDOAudit) that are able to map a String ID to an instance. > > b) Extension points for both CDOSession and CDOView (CDOTransaction and > CDOAudit might need separate extension points) that are able to instantiate > identifiable instances and register them with the registries (a). >
I would see the two registries similar to the global EPackage.Registry of EMF. It has no configuration but is initially populated through the extension points. The user interface could manage preference pages to further configure the registries and persist/load the settings as needed. Of course the registry must be prepared to have lazy descriptors registered by the extension points. A CDOEditor is always associated with a view so the existing CDOEditorInput is already appropriate. What about a dropdown main menu action with an Open Editor action for each registered view?!
Re-assigning to Vik in preparation of his new committer state...
Eike, André, it looks like bug #246623 might fulfil the requirements initially stated by André. Definitions in combination with some preferences UI should suffice. Eike, do you still want these extension points and registries to be done?
Rebasing all unresolved enhancement requests to 3.0
Rebasing all outstanding enhancements requests to version 4.0
Moving all open enhancement requests to 4.1
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Moving all outstanding enhancements to 4.3
Moving all open enhancement requests to 4.4
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.
