Loogisen mallin integroinnin mallin ohjetiivistelmä

Seuraavassa on luettelo siitä, kuinka mallien toimittajat voivat hyödyntää työryhmän loogisten mallien tukea:

  1. Mukauta mallinäkymien mallielementit ResourceMapping-kohteeseen, jotta resursseihin perustuvat toiminnot näkyvät mallielementeissä.
  2. Varmista rekisteröimällä ModelProvider-kohde, että malli tarkistetaan, kun malliin liittyviin resursseihin kohdistetaan toimintoja.
  3. Varmista ResourceChangeValidator-kohteen avulla resursseihin kohdistuvien toimintojen yhteydessä, että resursseihin liittyvien mallielementtien mahdolliset sivuvaikutukset tulevat käyttäjän tietoon.
  4. Toteuttamalla IResourceMappingMerger-kohteen voit osallistua näyttöpäätteettömään yhdistämiseen, johon kuuluu malliin liittyviä resursseja.
  5. Rekisteröimällä teamContentProvider-kohteen voit osallistua työryhmän tarkastelutoimintoihin, kuten yhdistämisen esikatseluun.
  6. IHistoryPageSource-kohteen antamalla voit näyttää loogisen mallin historiatiedot työryhmän historiasivulla.
  7. Eclipse-tiedostojärjestelmän ohjelmointirajapinnan avulla voit käyttää malliprojektien etätilaa.
  8. SynchronizationStateTester-ohjelmointirajapinnan avulla voit varmistaa, että ne mallielementit, joilla ei ole yksi-yhteen-vastaavuutta resursseihin, koristellaan oikein.

Seuraavissa kohdissa kuvataan nämä seikat tarkemmin. Lisäosassa org.eclipse.team.examples.filesystem on esimerkki, joka havainnollistaa monia näistä seikoista. Voit kuitata projektin ulos CVS-tietovarastosta ja käyttää sitä viitteenä, kun luet tätä opetusohjelmaa. Vastuunrajoituslauseke: Esimerkkilisäosien lähdekoodi saattaa muuttua ajan myötä. Jos haluat saada tässä esimerkissä käytettyä koodia vastaavan version, voit kuitata projektin ulos käyttämällä version 3.2 tunnistetta (luultavasti R3_2) tai päivämäärän 28. kesäkuuta 2006 tunnistetta.

Resurssien vastaavuusmääritykset

Resurssien vastaavuusmäärityksen perusohjelmointirajapinta

Resurssien vastaavuusmäärityksen ohjelmointirajapinta on tarkoituksellisesti yksinkertainen, ja siitä on poistettu loogisen mallin käsittely. Työasema ei tämän liittymän avulla voi tuoda näkyviin loogisia malleja tai hankkia niitä koskevia lisätietoja. Sen tarkoitus on yksinkertaisesti määrittää yhden tai usean mallielementin vastaavuus työtilan resursseihin.

Ohjelmointirajapinta koostuu seuraavista luokista:

Kahdenlaiset lisäosat tarvitsevat tietoja resurssien vastaavuusmäärityksistä. Näitä ovat ne, jotka toimittavat mallin, joka koostuu työtilan resursseista tai on tehty pysyväksi niissä, ja ne, jotka kohdistavat resursseihin toimintoja. Edellinen ryhmä käsitellään seuraavassa kohdassa, jälkimmäinen kohdassa Loogisen mallin integroinnin tietovaraston ohjetiivistelmä.

Mallin mukautus ResourceMapping-kohteeseen

Lisäosat, jotka ovat mukauttaneet malliobjektinsa IResource-kohteeseen käyttääkseen resurssikohtaisia toimintoja pikavalikossa, voivat nyt mukauttaa ResourceMapping-kohteeseen, jos tarkempi kuvaus siitä, kuinka objekti mukautuu resursseihin, on hyödyllinen. Niiden ei kuitenkaan tarvitse tehdä sitä, jos siitä ei ole hyötyä. Esimerkiksi Java-käännösyksikön (eli *.java-tiedosto JDT-näkymässä), joka tällä hetkellä mukautuu IFile-kohteeseen, ei ole pakko mukautua ResourceMapping-yksikköön, koska siitä ei ole hyötyä. Java-paketin on kuitenkin mukauduttava ResourceMapping-kohteeseen osoittaakseen, että paketti koostuu vain vastaavan kansion eikä alikansioiden tiedostoista.

Suositeltu tapa mukauttaa mallielementit resurssin vastaavuusmääritykseen on käyttää sovittimen factory-metodia. Seuraavassa on kuvattu XML-merkinnät, joiden avulla voit lisätä sovittimen factory-metodin lisäosan manifest-tiedostoon.

   <extension
point="org.eclipse.core.runtime.adapters">
<factory
class="org.eclipse.example.library.logical.AdapterFactory"
adaptableType="org.eclipse.example.library.Book">
<adapter type="org.eclipse.core.resources.mapping.ResourceMapping"/>
</factory>
<factory
class="org.eclipse.example.library.logical.AdapterFactory"
adaptableType="org.eclipse.example.library.Library">
<adapter type="org.eclipse.core.resources.mapping.ResourceMapping"/>
</factory>
...
</extension>

Sovittimen factory-toteutus näyttää jotakuinkin seuraavalta:

public class AdapterFactory implements IAdapterFactory {
public Object getAdapter(Object adaptableObject, Class adapterType) {
if((adaptableObject instanceof EObject) && adapterType == ResourceMapping.class) {
return new EObjectResourceMapping((EObject)adaptableObject);
}
return null;
}

public Class[] getAdapterList() {
return new Class[] {ResourceMapping.class};
}
}

Malliobjektit voivat toteuttaa IAdaptable-liittymän. Kun ne tekevät niin, niiden on varmistettava, että Platform-sovittimen hallintaohjelma tarkistetaan. Tämän voi tehdä luomalla PlatformObject-kohteelle aliluokan tai käyttämällä seuraavaa koodiriviä:

Platform.getAdapterManager().getAdapter(Object, Class)

Yllä oleva on suositeltu toimintatapa. Malliobjekti voi kuitenkin toteuttaa IAdaptable-liittymän ja toimittaa getAdapter(Class)-toteutuksen, joka luo ResourceMapping-ilmentymän nimenomaisesti, kun sellaista pyydetään. Tämä on suoraviivaisempi toimintatapa, mutta vähemmän toivottava, koska malli tarvitsee tarkat tiedot sovituksesta resursseihin.

Joissakin tapauksissa loogisen mallin toimittaja ei ehkä halua mallin mukautuvan IResource-kohteeseen kaikissa yhteyksissä tai haluaa objektin mukautuvan eri tavalla objektin lisäyksissä kuin muissa yhteyksissä. Työympäristön käyttöliittymässä on erityinen välisovitinohjelmointirajapinta, IContributorResourceAdapter, tällaisia tilanteita varten. Kun objektit mukautetaan IResource-kohteeseen objektien lisäyksen yhteydessä, työympäristö yrittää ensin mukauttaa resurssin IContributorResourceAdapter-kohteeseen, ennen kuin yrittää mukauttaa suoraan IResource-kohteeseen. Tähän liittymään on lisätty uusi aliliittymä, IContributorResourceAdapter2, jolla on samat toiminnot kuin ResourceMapping-kohteella. Ainoa ero on, että mallin toimittajan on rekisteröitävä factory-metodi IContributorResourceAdapter-kohteelle, koska työympäristö tekee instanceof-tarkistuksen varmistaakseen, onko lisätty sovitin myös IContributorResourceAdapter2-ilmentymä.

Java-paketin ResourceMapping-aliluokan toteutus näyttää seuraavalta.

public class JavaPackageResourceMapping extends ResourceMapping {
IPackageFragment package;
...
public getModelObject() {
return package;
}
public ResourceTraversals[] getTraversals(
ResourceMappingContext context,
IProgressMonitor monitor) {
return new ResourceTraversal[] {
new ResourceTraversal(
new IResource[] { package.getCorrespondingResource() },
IResource.DEPTH_ONE, IResource.NONE)
}
}
}

Tämä on melko yksinkertainen vastaavuusmääritys, joten toteutus ei ole monimutkainen. Resurssien vastaavuusmäärityksen toteutuksen monimutkaisuus vaihtelee tietenkin mallista toiseen.

Resurssien vastaavuusmäärityksen konteksti

Eräs resurssien vastaavuusmäärityksen ohjelmointirajapinnan eduista on, että sen avulla lisäosat voivat toteuttaa minkä tahansa haluamansa toiminnon resurssien vastaavuusmäärityksenä (esimerkiksi CVS-päivitys, CVS-muutosvahvistus, CVS-tunniste tai tallentamaton koristelu). Ohjelmointirajapinta käsittelee kuitenkin vain mallin paikallista tilaa. Kun käsittelet mallia, joka voi olla useiden kehittäjien yhteiskäytössä, tuloksena on tilanne, jossa mallin etätila (eli sellaisen mallin tila, jonka joku toinen käyttäjä on kuitannut sisään tietovarastoon) voi erota työtilassa olevasta tilasta. Jos toteutit CVS-päivityksen, haluat mallin paikallisen tilan vastaavan etätilaa, vaikka se tarkoittaisi, että lisätiedostoja on sisällytettävä tai joitakin tiedostoja poistettava.

Tämä ei ole ongelma joissakin loogisissa malleissa. Esimerkiksi Java-paketti on säilö, jonka läpikäynnin syvyys on yksi huolimatta mallin etätilasta. Näin ollen tietovaraston toimittaja voi helposti selvittää, että lähtevät poistot on sisällytettävä muutosten vahvistuksessa tai että saapuvat lisäykset on sisällytettävä päivitysten yhteydessä. Jotkin loogiset mallit muodostavat resurssit voivat kuitenkin muuttua ajan myötä. Esimerkiksi mallielementin muodostavat resurssit voivat olla alisteisia manifest-tiedoston sisällölle (tai vastaavalle mekanismille). Jotta resurssien vastaavuusmääritys palauttaa oikean läpikäynnin, sillä on oltava pääsy manifest-tiedoston etäsisältöön (jos se eroaa paikallisesta sisällöstä), jotta nähdään, onko muitakin resursseja sisällytettävä. Näitä lisäresursseja ei välttämättä ole työtilassa, mutta tietovaraston toimittaja voi varmistaa, että ne ovat, kun valittu toiminto toteutetaan.

Näiden monimutkaisempien mallien tuki edellyttää, että RemoteResourceMappingContext-kohde voidaan välittää ResourceMapping#getTraversals-metodille. Kun konteksti annetaan, vastaavuusmääritys voi sen avulla varmistaa, että kaikki tarvittavat resurssit on sisällytetty läpikäyntiin. Jos kontekstia ei anneta, vastaavuusmääritys voi olettaa, että vain paikallinen tila on tärkeä.

Milloin ResourceMapping-kohteen on huolehdittava RemoteResourceMappingContext-kohteesta?

ResourceMapping-kohteen tarvitsee huolehtia getTraversals-metodille toimitetusta kontekstista vain silloin, kun mallin muodostavat resurssit muuttuvat ajan myötä eikä mallin ja resurssien välistä suhdetta voi kuvata yksinkertaisen läpikäynnin avulla, joka varmasti kattaa kaikki kyseiset mallin muodostavat resurssit (ja vain ne). Vaikka esimerkiksi Java-paketin resurssit voivat muuttua ajan myötä, paketin voi kuvata kansiona, jonka syvyys on yksi, joten Java-pakettien resurssien vastaavuusmäärityksen ei tarvitse käyttää resurssien vastaavuusmäärityksen kontekstia.

Seuraavaksi tarkastellaan monimutkaisempana esimerkkinä HTML-tiedostoa, joka sisältää useita kuvia. Oletetaan, että kaikki HTML-tiedoston kuvaviitteet ovat osa kyseisen tiedoston mallia. Kun HTML-tiedoston paikallista sisältöä päivitetään tietovarastosta, käyttäjä olettaa, että uudet kuvat sisällytetään. HTML-tiedoston mallin ResourceMapping-kohteen getTraversals-metodi näyttää seuraavalta:

public class HTMLResourceMapping extends ResourceMapping {
private HTMLFile htmlFile;
public ResourceTraversal[] getTraversals(ResourceMappingContext context,
IProgressMonitor monitor)
IResource[] resources = htmlFile.getResources();
if (context instanceof RemoteResourceMappingContext) {
// Hae lisäresursseja palvelimesta
RemoteResourceMappingContext remoteContext = (RemoteResourceMappingContext)context;
IFile file = htmlFile.getFile();
if (remoteContext.hasRemoteChange(file, monitor)) {
IStorage storage = remoteContext.fetchRemoteContents(file, monitor);
IResource[] additionalResources = getReferences(storage.getContents());
resources = combine(resources, additionalResources);
}
if (remoteContext.isThreeWay() && remoteContext.hasLocalChange(file, monitor)) {
IStorage storage = remoteContext.fetchBaseContents(file, monitor);
IResource[] additionalResources = getReferences(storage.getContents());
resources = combine(resources, additionalResources);
}
}
return new ResourceTraversal[] {
new ResourceTraversal(resources, IResource.DEPTH_ZERO, IResource.NONE)};
}
}

Huomaa, että malliin kuuluu kahdenlaisia resurssijoukkoja: ne, jotka on johdettu työtilan HTML-tiedoston paikallisesta sisällöstä, ja ne, jotka on noudettu etätiedoston ja perustiedoston sisällöstä. Kummassakin näistä joukoista voi olla resursseja, joita ei ole työtilassa. Esimerkiksi paikallinen HTML-tiedosto voi sisältää suhteellisen linkin kuvaan, jota ei ole työtilassa. Tämä resurssi on sisällytettävä, jotta se noudetaan, mikäli se on etäsijainnissa. Etätiedostossa voi olla uusi kopio, joka viittaa lisäkuviin, jotka on noudettava, kun uusi etäsisältö ladataan.

Mallien toimittajat

Mallien toimittajat ovat keino ryhmittää joukko toisiinsa liittyviä resurssien vastaavuusmäärityksiä yhteen. Seuraavassa on ModelProvider-luokan linkki. Tällä luokalla on kolme päätarkoitusta:

  1. Mallin toimittajasta työasemat voivat noutaa lisää ohjelmointirajapintoja toimintojen toteutukseen resurssien vastaavuusmääritysjoukossa mukautusmekanismin avulla. Esimerkiksi mallin IResourceMappingMerger noudetaan mukauttamalla mallin toimittaja.
  2. Jos käytössä on joukko tiedostojärjestelmäresursseja, työasemat voivat kysellä, onko mallien toimittajalla pysyviä mallielementtejä kyseisissä resursseissa, ja mikäli on, noutaa suhdetta kuvaavan resurssien vastaavuusmääritysten joukon.
  3. Jos kyseessä ovat resurssijoukkoon kohdistuvat toiminnot, resurssien muutosten tarkistus kyselee mallien toimittajia selvittääkseen, onko toiminnolla mahdollisia sivuvaikutuksia, joista käyttäjän pitäisi olla tietoinen. Tätä on käsitelty erikseen kohdassa muutoksen tarkistus.

Seuraavassa on esimerkki modelProvider-laajennuksen määrityksestä.

   <extension
id="modelProvider"
name="Kirjastoesimerkki"
point="org.eclipse.core.resources.modelProviders">
<modelProvider
class="org.eclipse.team.examples.library.adapt.LibraryModelProvider"
name="Kirjastoesimerkki"/>
<extends-model id="org.eclipse.core.resources.modelProvider"/>
<enablement> <test property="org.eclipse.core.resources.projectNature" value="org.eclipse.team.examples.library.view.nature" />
</enablement>
</extension>

LibraryModelProvider on luokan ModelProvider aliluokka. Käyttöönottosääntöä käytetään täsmäyttämään resurssit, joissa kirjastomalli tekee mallin pysyväksi. Edellisessä esimerkissä mallin toimittaja täsmäyttää kaikki resurssit projektissa, jolla on kirjastoluonne.

Kun mallin toimittaja on määritetty, ResourceMapping#getModelProviderId()-metodi on ohitettava, jotta mallin toimittajan tunnus palautuu.

   public String getModelProviderId() {
return "org.eclipse.team.examples.library.adapt.modelProvider";
}

Jos haluat noutaa resurssien vastaavuusmäärityksen oikean käänteismäärityksen resursseille, jotka vastaavat toimittajan käyttöönottosääntöä, sinun on myös ohitettava ainakin toinen getMapping-metodi. Ohitettava metodi määräytyy sen mukaan, onko mallissa elementtejä, jotka sisältävät useita resursseja. Jos mallielementeille määritetään vastaavuus yhteen resurssiin, voit ohittaa sen metodin, joka hyväksyy yhden IResource-argumentin. Muussa tapauksessa on ohitettava se metodi, joka hyväksyy resurssimatriisin. Seuraavassa on esimerkki yhden resurssin tapauksesta.

Seuraavassa esimerkissä metodi kierrättää kirjastomallitiedoston asianmukaiseen resurssin vastaavuusmääritykseen. Se kierrättää myös kansiot, jotka sisältävät mallin toimittajan kannalta tärkeitä tiedostoja.

public class LibraryModelProvider extends ModelProvider {
public ResourceMapping[] getMappings(IResource resource,
ResourceMappingContext context, IProgressMonitor monitor) {
if (isModelFile(resource)) {
// Palauta tiedoston resurssivastaavuusmääritys
return new LibraryResourceMapping(resource);
} if (containsModelFiles(resource)) {
// Luo tarkka resurssivastaavuusmääritys säilöön
return new LibraryContainerResourceMapping(resource);
}
// Resurssi ei ole olennainen tälle mallin toimittajalle
return null;
}
}

Sen jälkeen työasemat voivat mallien toimittajan avulla selvittää, ovatko toiminnon kohteena olevat resurssit tärkeitä mallin toimittajalle. Seuraavassa kohdassa kuvataan ohjelmointirajapinta, joka toimitetaan mallien toimittajan ohjelmointirajapintaa käyttäville työryhmätoiminnoille sen resurssien vastaavuusmääritysten koko joukon selvittämiseksi, joka on kohteena, kun työryhmätoiminto toteutetaan valitussa resurssien tai mallielementtien joukossa.

Resurssin muutoksen tarkistus

Resursseihin kohdistetut toiminnot kannattaa aina ensin tarkistaa sen varmistamiseksi, että käyttäjä on tietoinen mahdollisista sivuvaikutuksista. Seuraavassa on kuvattu resurssin muutoksen tarkistuksen edellyttämät vaiheet.

  1. Luo kuvaus muutoksesta IResourceChangeDescriptionFactory-kohteen avulla. Factory-metodi tuottaa IResourceDelta-kohteen, joka vastaa sitä, miltä tuloksena oleva resurssidelta näyttää, kun toiminto on valmis.
  2. Tarkista muutos ResourceChangeValidator-kohteen avulla. Tarkistustoiminto tarkistaa kaikki mallien toimittajat, jotka on rekisteröity kiinnostuneiksi vaikutuksen kohteena olevista resursseista. Tuloksena on ainakin yksi tila, joka sisältää alkuperäisen mallin tunnuksen ja kuvauksen toiminnon mallille aiheuttamista mahdollisista sivuvaikutuksista.
  3. Ilmoita käyttäjälle sellaisten mallien mahdollisista sivuvaikutuksista, joita toiminnon aloittaja ei tunne. Jos esimerkiksi Java-koodinparannus on saanut sivuvaikutuksen Java-mallista, sen voi ohittaa, koska koodinparannus ymmärtää Java-mallin semantiikan. Jos tuloksena kuitenkin palautuu kirjastomallin sivuvaikutus, siitä on ilmoitettava käyttäjälle, koska Java ei tunne kirjastomallia.

Malliin perustuva yhdistäminen

Kun työryhmän toimittaja yrittää näyttöpäätteetöntä yhdistämistä, se tekee seuraavat toimet:

  1. hankkii valittujen elementtien resurssien vastaavuusmääritykset
  2. selvittää asiaan liittyvät mallin toimittajat ResourceMapping#getModelProvider()-metodin avulla
  3. laajentaa toiminnon aluetta kattamaan kaikki tarvittavat resurssien vastaavuusmääritykset
  4. luo kuvauksen etäsijainnin ja paikallisen sijainnin välisen synkronoinnin tilasta; kuvaus toimitetaan malleille IMergeContext-ohjelmointirajapinnan avulla
  5. mukauttaa mallien toimittajat IResourceMappingMerger-kohteeseen
  6. varmistaa, ettei mikään estä yhdistämistä kutsumalla validateMerge-metodin kunkin yhdistämisen yhteydessä ja välittämällä synkronoinnin kuvauksen
  7. delegoi yhdistämisen toteutuksen mallien yhdistämiselle.
  8. Mallien toimittajat voivat delegoida yksittäisten tiedostojen yhdistämisen takaisin työryhmän toimittajalle, jos ne haluavat vain hallita yhdistämisen järjestystä, tai toteuttaa yhdistämisen itse ja ilmoittaa työryhmän toimittajalle, kun tehtävä on valmis.

Mallin sisältö työryhmän toimintonäkymässä

Mallielementtien näyttö työryhmätoiminnon kontekstissa on mahdollista yhteisen navigaattorin kehyksen avulla.

Edellä kuvattujen vaiheiden avulla mallit voi tuoda näkyviin työryhmätoimintojen käyttämissä valintaikkunoissa. Integrointi yhdistämisen esikatseluun edellyttää lisävaiheita.

Historianäkymä

Tiedostohistorian ja mallielementtien historian suhteen on tehty seuraavat parannukset:

Etäselaus

Etäselaukselle on seuraava tuki:

Työryhmätilan mallielementtien koristelu

Työryhmän toimittajat voivat koristella mallielementit muuntamalla niiden kevyet koristeet toimimaan resurssien vastaavuusmäärityksissä samalla tapaa kuin objektilisäykset muunnetaan toimimaan resurssien vastaavuusmäärityksissä. Loogisten mallien elementtien koristelussa on kuitenkin eräs ongelma. Jos mallielementillä ei ole yksi-yhteen-vastaavuutta resurssiin, mallielementin nimiötä ei ehkä päivitetä, kun perustana olevat resurssit muuttuvat.

Ongelman ratkaisemiseksi on otettu käyttöön ITeamStateProvider-kohde, jonka avulla mallien toimittajat voivat käyttää työryhmäkoristeluihin ehkä vaikuttavia tilan muutoksia. Lisäksi mallinäkymät voivat selvittää SynchronizationStateTester-kohteen avulla, milloin loogisen mallin elementtien nimiöt on päivitettävä. Tämä ohjelmointirajapinta selvittää ITeamStateProvider-liittymän avulla, milloin resurssin työryhmätila on muuttunut ja voidaan välittää työryhmän koristelutoiminnolle osana IDecorationContext-kohdetta.