Arbejdsbænken indeholder et omfattende sæt af klasser og grænseflader til bygning af komplekse brugergrænseflader. Du behøver heldigvis ikke at forstå dem alle for at gøre noget enkelt. Vi starter med at se på nogle begreber, som afdækkes på arbejdsbænkens brugergrænseflade, og deres tilsvarende struktur under overfladen.
Udtrykket arbejdsbænk er blevet brugt løseligt til at referere til "det vindue, der åbnes, når du starter platformen". Lad os gå lidt i dybden og se på nogle af de synlige komponenter, som udgør arbejdsbænken.
I resten af denne beskrivelse refereres der til arbejdsbænksvinduet (IWorkbenchWindow), når udtrykket arbejdsbænk bruges. Arbejdsbænksvinduet er det overordnede vindue på arbejdsbænken. Det er den ramme, der indeholder menulinjen, værktøjslinjen, genvejslinjen og siderne. Generelt set har du ikke brug for at programmere arbejdsbænksvinduet. Du har kun brug for at vide, at det findes.
Bemærk: Du kan åbne flere arbejdsbænksvinduer, men hvert arbejdsbænksvindue er en selvstændig verden af egne editorer og oversigter, så vi vil nøjes med at fokusere på et enkelt arbejdsbænksvindue.
Set fra brugerens synsvinkel indeholder en arbejdsbænk oversigter og editorer. Der er nogle få andre klasser, som bruges til at implementere arbejdsbænksvinduet.
Inde i arbejdsbænksvinduet findes en side, IWorkbenchPage, som igen indeholder dele. Sider er en implementeringsmekanisme til gruppering af dele. Du har normalt ikke brug for at programmere siden, men den vises i sammenhæng med programmering og fejlfinding.
Perspektiver giver et ekstra lag af organisering på arbejdsbænkssiden. Et perspektiv definerer en relevant samling af oversigter, deres layout og passende funktioner for en given brugeropgave. Brugerne kan skifte mellem perspektiver, når de arbejder med opgaverne. Set fra en implementeringssynvinkel, styrer brugerens aktive perspektiv, hvilke oversigter der vises på arbejdsbænkssiden, samt deres placering og størrelse. Editorer påvirkes ikke af en perspektivændring.
Oversigter og editorer er dér, hvor vi skifter fra implementeringsdetaljer til generel plugin-programmering. Når du tilføjer en visuel komponent til arbejdsbænken, skal du beslutte, om du vil implementere en oversigt eller en editor. Hvordan beslutter du det?
Du skal i begge tilfælde bygge din egen oversigt eller editor, som overholder en generel livscyklus.
I løbet af livscyklussen startes der aktiviteter fra den indeholdende arbejdsbænk, som giver de interesserede parter besked om åbning, aktivering, deaktivering og lukning af oversigterne og editorerne.
Ser det let ud? Det kan det være. Det er skønheden ved oversigter og editorer på arbejdsbænken. De er blot pladsholdere til widgets, og kan være lige så enkle eller komplicerede, som der er behov for. Vi har tidligere set på de mest enkle oversigter, da vi byggede en oversigt til Hello World. Vi skal nu se på den igen, efter at vi gennemgået flere oplysninger om, hvad der sker.
package org.eclipse.examples.helloworld; import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.widgets.Label; import org.eclipse.swt.SWT; import org.eclipse.ui.part.ViewPart; public class HelloWorldView extends ViewPart { Label label; public HelloWorldView() { } public void createPartControl(Composite parent) { label = new Label(parent, SWT.WRAP); label.setText("Hello World"); } public void setFocus() { // set focus to my widget. For a label, this doesn't // make much sense, but for more complex sets of widgets // you would decide which one gets the focus. } }
Bemærk, at det ikke var nødvendigt at implementere en dispose()-metode, fordi vi ikke gjorde andet end at oprette en etiket i metoden createPartControl(parent). Hvis der var allokeret en brugergrænsefladeressource, som f.eks. billeder eller fonte, skulle de fjernes her. Eftersom ViewPart-klassen blev udvidet, overtager vi "Ingen handling"-implementeringen af dispose().