| 255 |
that uses a <code>Subscriber</code> to access the necessary remote state. Clients |
that uses a <code>Subscriber</code> to access the necessary remote state. Clients |
| 256 |
that have a <code>Subscriber</code> do not need to do any additional work to |
that have a <code>Subscriber</code> do not need to do any additional work to |
| 257 |
get a resource mapping context.</p> |
get a resource mapping context.</p> |
| 258 |
<h2>How this will affect existing plug-ins</h2> |
<h2>EMF Library Example</h2> |
| 259 |
|
<p>This example, available <a href="../../../plugins/library.zip">here</a>, is |
| 260 |
|
built on a model that consists of libraries, books and writers. The code is |
| 261 |
|
generated by EMF. It requires Eclipse 3.1 M5 and EMF SDK 2.0.1.</p> |
| 262 |
|
<p> The model is persisted in several types of files:</p> |
| 263 |
|
<ul> |
| 264 |
|
<li>*.library files which contain the name of a library and one ofr more book |
| 265 |
|
copy records which reference a bokk and indicate the number of copies of the |
| 266 |
|
book the libraries contain.</li> |
| 267 |
|
<li>*.books files which contain one or more books. Each book has serveral properties |
| 268 |
|
(name, number of pages, etc.) as well as a reference to the book's author.</li> |
| 269 |
|
<li>*.writers files which contain one or more writers. Each writer has properties |
| 270 |
|
(e.g. name) as weel as references to one or more books that have been authored |
| 271 |
|
by the writer.</li> |
| 272 |
|
</ul> |
| 273 |
|
<p>The following screenshot shows an example Library.</p> |
| 274 |
|
<p><img src="libraryView.png" width="306" height="229"></p> |
| 275 |
|
<p>Here is the containment relationship of these model elements</p> |
| 276 |
|
<ul> |
| 277 |
|
<li>My.writers: contains "Bob"</li> |
| 278 |
|
<li>My.books: contains "The Life of Bob"</li> |
| 279 |
|
<li>mylib.library: contains copeis of the "Life of Bob"</li> |
| 280 |
|
</ul> |
| 281 |
|
<p>For the purposes of this example, model containment is determined by following |
| 282 |
|
all the references from the file containing the selected model element to all |
| 283 |
|
other files. For instance, the resources associated with the writer "Bob" |
| 284 |
|
would be My.writers, since Bob is contained in that file, and My.books since |
| 285 |
|
Bob wrote a book in that book catalog. The resources associated with the Main |
| 286 |
|
Library would be mylib.library, My.books, since the library contains a book |
| 287 |
|
from that catalog, and My.writers, since the it contains Bob, the auther of |
| 288 |
|
that book.</p> |
| 289 |
|
<p>There are three files of interest in the example code, all of them in the org.eclipse.team.examples.library.adapt |
| 290 |
|
plugin.</p> |
| 291 |
|
<ul> |
| 292 |
|
<li><em>org.eclipse.team.examples.library.adapt/plugin.xml</em>: containes the |
| 293 |
|
adapter factory registration and an object contribution to <code>ResourceMapping</code>.</li> |
| 294 |
|
<li><em>org.eclipse.team.examples.library.adapt/src/org/eclipse/team/examples/library/adapt/EMFResourceMapping</em>: |
| 295 |
|
The resource mapping from the Library model to resources. This is basically |
| 296 |
|
a worst-case mapping that uses EMF to traverse the modle for file references. |
| 297 |
|
Read the class javadoc for more information.</li> |
| 298 |
|
<li><em>org.eclipse.team.examples.library.adapt/src/org/eclipse/team/examples/library/adapt/ShowResourceMappingsAction</em>: |
| 299 |
|
The action that shows the resource mapping. At the time of writting it uses |
| 300 |
|
internal Team UI classes but the intention is to make these classes (or at |
| 301 |
|
least the funtionality they provide) API in 3.1.</li> |
| 302 |
|
</ul> |
| 303 |
|
<p>There is also a read-me file (<em>org.eclipse.team.examples.library.adapt/readme.html</em>) |
| 304 |
|
that contains instructions on how to use the example. </p> |
| 305 |
|
<h2>Conclusion</h2> |
| 306 |
|
<h3>How this will affect existing plug-ins</h3> |
| 307 |
<p>Existing plugins do not need to change at all unless they want to take advantage |
<p>Existing plugins do not need to change at all unless they want to take advantage |
| 308 |
of the new API. For plugins that provide logical modes, it may be worthwhile |
of the new API. For plugins that provide logical models, it may be worthwhile |
| 309 |
for them to adapt their model objects to <code>ResourceMappings</code>. Of course, |
for them to adapt their model objects to <code>ResourceMappings</code>. Of course, |
| 310 |
this is only a benefit when combined with a repository provider implementation |
this is only a benefit when combined with a repository provider implementation |
| 311 |
that contributes at last some of it's actions to resource mappings.</p> |
that contributes at last some of it's actions to resource mappings.</p> |
| 312 |
<span style="font-weight: bold;"></span> |
<span style="font-weight: bold;"></span> |
| 313 |
<h2>Open Issues</h2> |
<h3>Open Issues</h3> |
| 314 |
<p>The following issues would need to be addressed for this solutions.</p> |
<p>The following issues would need to be addressed for this solutions.</p> |
| 315 |
<ul> |
<ul> |
| 316 |
<li> Plugins that add object contributions will have to modify their actions |
<li> Plugins that add object contributions will have to modify their actions |
| 324 |
provider isn't mapping aware?</li> |
provider isn't mapping aware?</li> |
| 325 |
<li>What about reposiory providers that cannot provide a remote mapping context?</li> |
<li>What about reposiory providers that cannot provide a remote mapping context?</li> |
| 326 |
<li>What should a model provider do if they canno reliably determine the remote |
<li>What should a model provider do if they canno reliably determine the remote |
| 327 |
model state? </li> |
model state?<br> |
|
<li>Need to reference the example<br> |
|
| 328 |
</li> |
</li> |
| 329 |
</ul> |
</ul> |
| 330 |
</body> |
</body> |
Parent Directory
| 
Revision Log
| 
Patch