Når plattformen kjører og plugin-modulen for ressurser er aktiv, representeres arbeidsområdet av en forekomst av IWorkspace, som inneholder en protokoll for tilgang til ressursene den inneholder. En forekomst av IWorkspace representerer en tilknyttet samling av filer og kataloger i ett eller flere filsystemer. Du får tilgang til arbeidsområdet fra ressursenes plugin-klasse (som er definert i org.eclipse.core.resources).
IWorkspace workspace = ResourcesPlugin.getWorkspace();
Når ressursenes plugin-modul ikke kjører, eksisterer arbeidsområdet bare i filsystemet og vises eller manipuleres av brukeren via standard filbaserte verktøy. La oss se på hvordan et arbeidsområde ser ut på disk mens vi forklarer programmeringsgrensesnittet for ressursenes plugin-modul.
Da du startet SDK for plattformen, ble du bedt om å oppgi katalog for arbeidsområdet. Dette er katalogen der forskjellige plugin-moduler lagrer interessante metadata som er unike for en bestemt forekomst av plattformen. Som standard lagrer ressursenes plugin-modul hvert prosjekt i en underkatalog under arbeidsområdekatalogen. I disse underkatalogene finner du mappene og filene for hvert prosjekt.
La oss si at du har valgt katalogen c:\MySDK\workspace for arbeidsområdet. Innenfor denne katalogen finner vi underkataloger oppkalt etter arbeidsområdets prosjekter, MyWeb og MyServlet. Disse kalles prosjektenes innholdskataloger. Innholdskataloger opprettes av plattformen når brukeren oppretter et prosjekt.
I hver katalog finner vi filer og mapper i prosjektet, plassert på akkurat samme måte som i ressurstreet i arbeidsområdet. Alle filnavn er like og filinnholdet er identisk uavhengig av om filene åpnes fra filsystemet eller fra arbeidsområdet. Den eneste overraskelsen er filen .project, som vi straks skal se nærmere på.
C:\MySDK\workspace (workspace root) .metadata\ (platform metadata directory MyWeb\ (project content directory for MyWeb) .project index.html images\ logo.png MyServlet\ (project content directory for MyServlet) .project src\ main.java bin\ main.class
Plattformen har en bestemt .metadata-katalog som inneholder plattformintern informasjon. Katalogen .metadata i et arbeidsområde blir betraktet som en "ferdsskriver". Metadatadelen av arbeidsområdet lagrer viktig informasjon om arbeidsområdestrukturen, for eksempel referanser for et prosjekt eller egenskaper for en ressurs, og skal bare åpnes av verktøy gjennom plattformens programmeringsgrensesnitt. Disse filene skal ikke redigeres eller manipuleres ved hjelp av programmeringsgrensesnittet for det generiske filsystemet.
I tillegg har hvert prosjekt sin egen .project-fil som inneholder metadata om prosjektet. Filen er diskens motsvar på informasjonen i IProjectDescription i et prosjekt.
Med unntak av .metadata-katalogen og .project-filene, står andre verktøy fritt til å bruke mappene og filene i katalogen workspace. Filene og mappene kan manipuleres av verktøy som ikke er integrert, for eksempel tekstredigeringsprogrammer og filsystemfunksjoner. Det eneste er at brukeren må være forsiktig ved redigering av disse filene både i arbeidsbenken og eksternt. (Dette er det samme som når en bruker redigerer en fil ved hjelp av to frittstående verktøy.) Arbeidsbenken inneholder oppdateringsoperasjoner for avstemming av arbeidsområdevisningen for ressurser med den faktiske tilstanden i filsystemet, og oppdaterer regelmessig arbeidsområdet basert på tilstanden i filsystemet.
Programmeringsgrensesnittet for ressursen gjør det mulig å manipulere dette ressurstreet med kode. Vi skal se på noen kodesnutter for å få en rask innføring i programmeringsgrensesnittet for ressursen. Programmeringsgrensesnittet for ressursen defineres i en serie med grensesnitt i org.eclipse.core.resources. Det finnes grensesnitt for alle ressurstypene, for eksempel IProject, IFolder og IFile. Det er definert en omfattende fellesprotokoll i IResource. Vi kan også bruke org.eclipse.core.runtime-grensesnittet IPath, som representerer segmenterte baner som ressurser og filsystembaner.
Manipulering av ressurser er svært likt manipulering av filer ved hjelp av java.io.File. Programmeringsgrensesnittet er basert på referanser. Når du bruker programmeringsgrensesnitt som getProject eller getFolder, returneres en referanse til ressursen. Det er ingen garant eller krav om at selve ressursen eksisterer før du forøker å utføre noe med referansen. Hvis du tror at en ressurs finnes, kan du bruke metoden exists for å kontrollere at så er tilfelle.
Hvis du vil navigere i arbeidsområdet fra en plugin-modul, må du først hente IWorkspaceRoot, som representerer det øverste ressurshierarkiet i arbeidsområdet.
IWorkspaceRoot myWorkspaceRoot = ResourcesPlugin.getWorkspace().getRoot();
Når vi har en arbeidsområderot, får vi tilgang til prosjektene i arbeidsområdet.
IProject myWebProject = myWorkspaceRoot.getProject("MyWeb"); // åpne om nødvendig if (myWebProject.exists() && !myWebProject.isOpen()) myWebProject.open(null);
Et prosjekt må åpnes før det kan manipuleres. Når prosjektet åpnes, leses prosjektstrukturen fra disk og det opprettes en minneobjektrepresentasjon av ressurstreet for prosjektet. Det er en eksplisitt operasjon å åpne et prosjekt siden hvert åpne prosjekt bruker minne til å representere ressurstreet internt, og åpne prosjekter deltar i ulike ressurslivssyklushendelser (for eksempel en bygging) som kan være tidkrevende. Generelt kan ikke lukkede prosjekter åpnes og er tilsynelatende tomme selv om ressursene fortsatt ligger i filsystemet.
Du vil se at mange av disse ressurseksemplene sender en null-parameter når de manipulerer ressurser. Mange ressursoperasjoner har nok tyngde til å sikre fremdriftsrapportering og brukeravbrudd. Hvis koden har et brukergrensesnitt, kan du vanligvis sende en IProgressMonitor slik at ressursenes plugin-modul kan rapportere fremdrift etter hvert som ressursen manipuleres, og lar eventuelt brukeren avbryte operasjonen. Foreløpig skal vi imidlertid bare sende null, som angir at det ikke finnes fremdriftsovervåker.
Når vi har et åpent prosjekt, får vi tilgang til mappene og filene i tillegg til å opprette nye. I eksempelet nedenfor oppretter vi en filressurs fra innholdet i en fil som ligger utenfor arbeidsområdet.
IFolder imagesFolder = myWebProject.getFolder("images"); if (imagesFolder.exists()) { // opprett ny fil IFile newLogo = imagesFolder.getFile("newLogo.png"); FileInputStream fileStream = new FileInputStream( "c:/MyOtherData/newLogo.png"); newLogo.create(fileStream, false, null); // opprettelse lukker filstrømmen, så alt i orden }
I eksempelet ovenfor henter første linje en referanse til bildemappen. Før vi kan gjøre noe som helst med mappen, må vi kontrollere at den eksisterer. Og tilsvarende, når filen newLogo hentes, representerer ikke referansen en reell fil før vi oppretter filen på siste linje. I dette eksempelet oppretter vi filen ved å fylle ut med innholdet fra logo.png.
Neste snutt likner på den forrige, bortsett fra at den kopierer newLogo-filen fra den opprinnelige logoen i stedet for å opprette en ny på bakgrunn av innholdet.
IFile logo = imagesFolder.getFile("logo.png"); if (logo.exists()) { IPath newLogoPath = new Path("newLogo.png"); logo.copy(newLogoPath, false, null); IFile newLogo = imagesFolder.getFile("newLogo.png"); ... }
Vi skal til slutt opprette en ny bildemappe og flytte den nyopprettede filen dit. Vi endrer navnet på filen som en del av det å flytte den.
... IFolder newImagesFolder = myWebProject.getFolder("newimages"); newImagesFolder.create(false, true, null); IPath renamedPath = newImagesFolder.getFullPath().append("renamedLogo.png"); newLogo.move(renamedPath, false, null); IFile renamedLogo = newImagesFolder.getFile("renamedLogo.png");
Mange av ressursens programmeringsgrensesnittmetoder omfatter et boolsk force-flagg som angir om ressurser som ikke er synkronisert med de tilsvarende filene i filsystemet, likevel skal oppdateres. Du finner er informasjon i IResource. Du kan også bruke IResource.isSynchronized for å finne ut om en bestemt ressurs er synkronisert med filsystemet.
I eksempelet på ressurstre har vi forutsatt at alle kataloger med prosjektinnhold ligger i katalogen workspace under plattformens rotkatalog (C:\MySDK\workspace). Dette er standardkonfigureringen for prosjekter. Innholdskatalogen for et prosjekt kan imidlertid tilordnes på nytt til en vilkårlig katalog i et understøttende filsystem, kanskje til og med på en annen maskin.
Det å kunne tilordne plasseringen av et prosjekt uavhengig av andre prosjekter, gjør det mulig for brukeren å lagre innholdet i et prosjekt på et sted som er fornuftig både med tanke på prosjektet og prosjektgruppen. Innholdskatalogen for et prosjekt anses som "fleksibelt". Dette betyr at brukeren kan opprette, endre og slette ressurser ved å bruke arbeidsbenken og plugin-moduler eller ved å bruke filsystembaserte verktøy og redigeringsprogrammer direkte.
Ressursbanenavn er ikke fullstendige filsystembaner. Ressursbaner bygger alltid på prosjektets plassering (vanligvis workspace-katalogen). Hvis du vil ha fullstendig filsystembane til en ressurs, må du sende en spørring etter plasseringen ved hjelp av IResource.getLocationURI. Du kan imidlertid ikke bruke IProjectDescription.setLocation til å endre plasseringen, fordi metoden bare er en enkel setter-metode for en datastruktur.
Hvis du vil hente det tilsvarende ressursobjektet med en gitt filsystembane, kan du bruke IWorkspaceRoot.findFilesForLocationURI eller IWorkspaceRoot.findContainersForLocationURI.
Når vi endrer arbeidsområdets ressurstre ved hjelp av programmeringsgrensesnittet for ressurser, endres filene i filsystemet i tillegg til å oppdatere ressursobjektene. Hva med endringer i ressursfiler som skjer utenfor plattformens programmeringsgrensesnitt?
Eksterne endringer i ressurser gjenspeiles ikke i arbeidsområdet og ressursobjektene før ressursenes plugin-modul oppdager dem. Denne plugin-modulen har også egne mekanismer for hver enkelt operativsystem slik at den oppdager eksterne endringer som er utført i filsystemet. I tillegg er det mulig å bruke programmeringsgrensesnitt for ressursen til å avstemme arbeidsområde- og ressursobjekter med det lokale filsystemet. Dette skjer i bakgrunnen uten at brukeren trenger å gjøre noe. Brukeren kan også eksplisitt tvinge frem en oppdatering i ressursnavigatorvisningen i arbeidsbenken.
Mange av metodene i programmeringsgrensesnittene for ressursen omfatter en parameter for tvinging som angir håndtering av ressurser som ikke er synkronisert med filsystemet. API-referansen for hver metode inneholder spesifikk informasjon om denne parameteren. Med øvrige metoder i programmeringsgrensesnittet er det mulig med programmatisk kontroll over filsystemoppdatering, for eksempel med IResource.refreshLocal(int depth, IProgressMonitor monitor). Du finner informasjon om kostnader og korrekt bruk i IResource.
Plugin-moduler som oppgir egne mekanismer for regelmessig oppdatering av arbeidsområdet basert på tilstanden i det eksterne filsystemet, må bruke utvidelsespunktet org.eclipse.core.resources.refreshProviders. Du finner mer informasjon under Oppdateringsleverandører.