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 "Recommenders/ExtDoc/Architecture"
< Recommenders | ExtDoc
| Line 58: | Line 58: | ||
=== Community Feedback === | === Community Feedback === | ||
| − | ... | + | *The loading of the data (from the database) and the creation of the user interface have to be separate to minimize the time spent in the UI thread. |
| + | *Therefore a CommunityFeedback object can be created by a provider while it "plans" the UI update, i.e., before the ProviderUiUpdateJob, which is performed in the UI thread, is created. | ||
| + | *As a result, the CommunityFeedback data is already loaded from the server. When constructing the actual composites/widgets inside the ProviderUiUpdateJob, only the UI elements (e.g., stars) are created for the data. | ||
== Providers == | == Providers == | ||
Revision as of 02:42, 7 November 2011
Contents
Plug-ins / Bundles
| commons.extdoc | Mostly interface that are shared among multiple ExtDoc plug-ins. |
| commons.selection | Listens for different types of user interaction with the IDE and reports Java element selections and corresponding Eclipse and Java contexts (editor, compilation unit, ...). |
| rcp.extdoc | Listens for selection changes, requests corresponding information from registered providers and controls the display in views and pop-ups. Also, it provides user preference pages, as well as common features such as community feedback widgets. |
| rcp.extdoc.providers | Providers create composites of selection-relevant information, which are then displayed by the rcp.extdoc plug-in. |
| server.extdoc | Contains interfaces to further software, such as databases, as well as the data types carrying the external/database information, such as the comments class. |
| server.extdoc.proxy | Serves as a proxy for CouchDB by listening to a given port and forwarding a limited set of requests to a CouchDB instance. |
Java Element Selections
- Client plug-ins register through an extension point.
- A general ISelectionListener is registered with the workbench and listens for all selections, except those in JavaEditors.
- An IPartListener recognizes newly created JavaEditors and, for each, registers a ISelectionChangedListener which listens for new cursor positions.
- On each selection change, an IJavaElementSelection is created, which contains the IJavaElement, element location, editor offset, CU, ASTNode and the editor (most of those only if the selection occurred within an editor).
- The IJavaElementSelection is communicated to each extension.
ExtDoc Client
General Architecture
- The ProviderStore contains all providers which are registered trough an extension point. Also, order priorities are stored.
- The UiManager is a client to the selections service. On incoming selections, it notifies the view (when visible). Also, the manager is informed when new editors are created and registers the ExtDocCodeAssistantHover on such events.
Providers Composites
- On top, the ProvidersComposite arranges all providers in a GridLayout.
- When registered with a ProvidersComposite (there are different ones for the view and the two hovers), each provider creates a basic composite.
- The basic composite is reused on each update, so a provider can just change single texts, tables, ... instead of having to create the same contents on each selection change.
AbstractTitledProvider
- When asked to create its composite, it constructs a composite containing a title bar on its own. The provider implementation is only asked to create the composite placed underneath the title bar.
- On selection changes, the provider implementation is only asked to create a ProviderUiUpdateJob, which, when executed, will perform the composite modifications (e.g. text updates) on a given composite.
- Using this structure, the providers do not have to worry about UI threads, layouting, etc., the executor of the job will do it. Also, UI updates can be organized instead of executed immediately.
- Currently however, the AbstractTitledProvider directly performs the update as soon as the ProviderUiUpdateJob is returned.
View Updates
- For each provider, a job is created, which will notify the provider of the new selection and give the provider's basic composite associated with the view's ProvidersComposite.
- In an extra thread, an ExecutorService then executes all jobs and waits until all are done or a time limit (2 sec) is exceeded.
- For jobs finished in time, their finishSuccessful() method is called, which, in the view context, unhides the provider and updates the table item.
- For uncompleted jobs, handleTimeout() is called. The current implementation resolves the actual content area (i.e., what's below the title bar) and replaces it with a timeout notification text.
Hovers
- Editor hovers as well as completion hovers use the IInformationControl interface and some of its extensions. Eclipse just takes the IInformationControl and feeds it with some data which it receives from the hover implementation.
- Basically, the ExtDoc hovers just resolve the selection context once a hover is activated and the IInformationControl implementation (AbstractHoverInformationControl) updates the ProvidersComposite it manages with the new selection.
Community Feedback
- The loading of the data (from the database) and the creation of the user interface have to be separate to minimize the time spent in the UI thread.
- Therefore a CommunityFeedback object can be created by a provider while it "plans" the UI update, i.e., before the ProviderUiUpdateJob, which is performed in the UI thread, is created.
- As a result, the CommunityFeedback data is already loaded from the server. When constructing the actual composites/widgets inside the ProviderUiUpdateJob, only the UI elements (e.g., stars) are created for the data.
Providers
...
Server
...
CouchDB Proxy
...