Bugzilla – Full Text Bug Listing
| Summary: | Rethink plugin-contributed highlight API | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Mark Macdonald <mamacdon> |
| Component: | Client | Assignee: | Mark Macdonald <mamacdon> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse.felipe, john.arthorne |
| Version: | 0.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Mark Macdonald
One way to fix this, in our current architecture, is to assign IDs to objects that a plugin is interested in, but that it cannot access directly. So we'd give a unique ID to every TextView, and then any API call that contains data from a TextView would include the TextView ID. For example, if you were writing a plugin that listened to a selection event, you would implement: onSelection(textViewId, selection) Rather than: onSelection(selection) The plugin would need to include this TextView ID in any data it sends back to Orion. If the plugin maintains any state between calls, it needs to store it per-TextView-instance so that one TextView cannot interfere with another. But this feels like a cumbersome workaround for not being able to pass a reference to the actual 'TextView' object to a plugin. I am worried that forcing this onto clients will make our APIs unpleasant to use. I guess I'm searching for the equivalent of an executable extension from Eclipse desktop. A plugin wants to contribute an implementation of some interface. When the core needs the contribution, it magically instantiates it into a first-class object, and then interacts with it like any other object. This allows more encapsulation because there may be many instances of a contribution, each with its own separate internal state. By contrast, in our current architecture, Orion plugins are singletons. The services they contribute are also singletons. The core talks to these singletons to get work done, but every API call must carry all the parameters necessary to disambiguate one (would-be) instance of a contribution from another. Not sure if I'm explaining this very well, but hopefully the example in Comment 1 made it clear. Yes it makes complete sense. Just to clarify though, on the "Coding" page there is only one text view so this isn't an issue right? I guess the problem would be compare pages, or git commit page, or any page showing multiple text views at once? (In reply to comment #3) > Yes it makes complete sense. Just to clarify though, on the "Coding" page there > is only one text view so this isn't an issue right? I guess the problem would > be compare pages, or git commit page, or any page showing multiple text views > at once? Yes, that's right. If a service knows it will never apply to more than one thing on a page, there's no problem. But I can see a lot of the "coding-page only" services eventually being useful in compare & git-commit pages too -- for example, something like "mark occurrences". Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html |