Difference between revisions of "Recommenders/ExtDoc/Architecture"

Revision as of 02:34, 7 November 2011

Plug-ins / Bundles

Java Element Selections

1. Client plug-ins register through an extension point.
2. A general ISelectionListener is registered with the workbench and listens for all selections, except those in JavaEditors.
3. An IPartListener recognizes newly created JavaEditors and, for each, registers a ISelectionChangedListener which listens for new cursor positions.
4. 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).
5. 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

1. 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.
2. In an extra thread, an ExecutorService then executes all jobs and waits until all are done or a time limit (2 sec) is exceeded.
3. For jobs finished in time, their finishSuccessful() method is called, which, in the view context, unhides the provider and updates the table item.
4. 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

...

Providers

...

Server

...

CouchDB Proxy

...