| 332 |
<span style="font-weight: bold;"></span> |
<span style="font-weight: bold;"></span> |
| 333 |
<h3>Open Issues</h3> |
<h3>Open Issues</h3> |
| 334 |
<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> |
| 335 |
<ul> |
<h4>UI Support</h4> |
| 336 |
<li> Plugins that add object contributions will have to modify their actions |
<p>Plugins that add object contributions will have to modify their actions to |
| 337 |
to handle logical resources. There should be some standard UI components for |
handle logical resources. There should be some standard UI components for showing |
| 338 |
showing the mappings. For instance you could show the logical model at the |
the mappings. For instance you could show the logical model at the top and in |
| 339 |
top and in a details part the physical files/folders that will be affected |
a details part the physical files/folders that will be affected by the operation. |
| 340 |
by the operation.</li> |
There is currently a <code>MappingSelectionDialog</code> in the Team UI plugin |
| 341 |
<li>Can the user benefit from resource mappings in cases where the repository |
but it is not yet API. The goal is to evolve this class to the point where it |
| 342 |
provider isn't mapping aware?</li> |
can be made API.</p> |
| 343 |
<li>What about reposiory providers that cannot provide a remote mapping context?</li> |
<h4><strong>Incomplete Implementations</strong></h4> |
| 344 |
<li>What should a model provider do if they cannot reliably determine the remote |
<p>Full support for resource mappings depends on these factors:</p> |
| 345 |
model state?<br> |
<ol> |
| 346 |
</li> |
<li>The model provides a resource mapping for its model elements</li> |
| 347 |
</ul> |
<li>Repository providers (or other tools) become resource mapping aware.</li> |
| 348 |
|
<li>Repository providers (or other tools) provide a resource mapping context |
| 349 |
|
for those operations that warrant it.</li> |
| 350 |
|
<li>Model that may have resources added or removed at the root level (i.e. the |
| 351 |
|
resources returned by the <code>ResourceTraversal#getResources()</code> method) |
| 352 |
|
make use of the context to determine any additional resources that should |
| 353 |
|
be included in the mapping.</li> |
| 354 |
|
</ol> |
| 355 |
|
<p>Without the first point, nothing can be done so this is really the main requirement. |
| 356 |
|
Assuming we have a model that provides a resource mapping, we end up with the |
| 357 |
|
following possible scenarios:</p> |
| 358 |
|
<p><strong>A repository provider is not mapping aware</strong>: In this case, |
| 359 |
|
the best that can be done is for the model (i.e. the model's view) to provide |
| 360 |
|
a Show In>Navigator command which will allow the user to perform Team operations |
| 361 |
|
from there. Of course, this is only an issue for model elements that do not |
| 362 |
|
map to a single resource. Although this is a bit cumbersome, it will work in |
| 363 |
|
many situations. It will not work well for those models that may have added |
| 364 |
|
or removed resources at the root level.</p> |
| 365 |
|
<p><strong>A repository provider does not provide a resource mapping context or |
| 366 |
|
a model does not make use of the context</strong>: For some repository providers, |
| 367 |
|
it may be difficult to provide a resource mapping context. It is also possible |
| 368 |
|
that a model may not make use of the context to determine which resource should |
| 369 |
|
be included in the mapping. In either case, this is only an issue for models |
| 370 |
|
that may add or remove resources at the root level. In reality, the number of |
| 371 |
|
these cases may be small bu the effects will be noticable since operations may |
| 372 |
|
exclude resources. These cases can be handled by falling back to operations |
| 373 |
|
on the resources themselves.<br> |
| 374 |
|
</p> |
| 375 |
</body> |
</body> |
| 376 |
</html> |
</html> |
Parent Directory
| 
Revision Log
| 
Patch