Seuraavassa on luettelo siitä, kuinka mallien toimittajat voivat hyödyntää työryhmän loogisten mallien tukea:
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ää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:
Object getModelObject()
: Malliobjekti, josta vastaavuusmääritys on johdettu (tai mukautettu).ResourceTraversal[]
getTraversals(ResourceMappingContext, IProgressMonitor)
: Resurssien läpikäynti, joka kattaa malliobjektin muodostavat objektit.ResourceTraversal
-kohde sisältää joukon resursseja ja syvyysmääritteen, joka osoittaa, mihin syvyyteen saakka läpikäynnin kohteena olevat resurssit liittyvät alkuperäiseen malliobjektiin. Resurssien vastaavuusmääritys mahdollistaa työasemalle resurssien läpikäynnin, jotta mallin sisältö voidaan kuvata sellaisella tavalla, että työasema (esimerkiksi tietovaraston toimittaja) voi toteuttaa toimintonsa mahdollisimman tehokkaasti. Kiinnostavat metodit ovat seuraavat:
getResources()
getDepth()
ResourceMappingContext
jaRemoteResourceMappingContext
käyttö on hieman monimutkaisempaa ja kuvataan kohdassa Resurssien vastaavuusmäärityksen konteksti.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ä.
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.
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ä.
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 ovat keino ryhmittää joukko toisiinsa liittyviä resurssien vastaavuusmäärityksiä yhteen. Seuraavassa on ModelProvider-luokan linkki. Tällä luokalla on kolme päätarkoitusta:
IResourceMappingMerger
noudetaan mukauttamalla mallin toimittaja.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.
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.
IResourceChangeDescriptionFactory
-kohteen avulla.
Factory-metodi tuottaa IResourceDelta
-kohteen, joka vastaa sitä, miltä tuloksena oleva resurssidelta näyttää, kun toiminto on valmis.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. Kun työryhmän toimittaja yrittää näyttöpäätteetöntä yhdistämistä, se tekee seuraavat toimet:
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.
Tiedostohistorian ja mallielementtien historian suhteen on tehty seuraavat parannukset:
Etäselaukselle on seuraava tuki:
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.