Community
Participate
Working Groups
With RSE 1.0, the complete state handling and life-cycle for system types are hidden within RSE. A contributor of a system has no chance to prevent things from happening (like connect on node expand). This is bad. Still it is a good idea to have default actions and life-cycle management for every system type or subsystem to allow easy startup, but it should be also possible for contributors to take over the complete handling of the nodes (starting with the system type node) in terms of states/life-cycle [delegates], context menu actions [delegates], toolbar actions [delegates] and label and content providers [delegates].
It looks like one step in the direction of allowing contributors more control over the system types has been done with the addition of the dynamic systemTypeContributor extension point (bug 172662). Since the extender is now able to register a systemTypeContributor, he can return a specialized systemType class (e.g. MySystemType implements IRSESystemType). This allows him to also register a corresponding AdpaterFactory and Adapter (MySystemTypeAdapter extends RSESystemTypeAdapter) where at least the isEnabled() method can be overridden to allow for dynamic enablement.
Part of the work has been done by fixing [176481]. SystemViewConnectionAdapter is only adding actions being approved by the system type provider via RSESystemTypeAdapter. The default implemention is to accept always all actions except those actions which had been conditions associated already within the original implementation.
Uwe do you think this can be marked fixed since your recent changes? Can you add references to related bugs you fixed into the "depends on" field?
Yes. This is done now. With recent changes the dynamic system type provider can gain full control of the system type actions without loosing any of the default RSE ones.
[target cleanup] 2.0 M6 was the original target milestone for this bug
