Description Dan Rubel 2003-07-04 11:22:02 EDT

From bug 38048, comment 4

"I understand your desire to add the confirmOverwrite method to confirm the 
overwrite of the projects. It greatly simplifies the implemenation of the 
ProjectSetSerializer for repository providers that only prompt for project 
overwrite. My concern is that it leaves repository providers who need to do more 
no better off then they are today."

Good point.  My original patch (see bug 38048, comment 9) does not address this 
issue but can provide the basis for a solution pending your approval.

Problem Summary:

Repository providers want to have their own project set context for UI based 
operations for a better more integrated user experience, yet repository 
consumers need to drive the repository in ways not originally envisioned by the 
repository providers.

Proposed Solution:

Repository providers may have their own *preferred* UI based project set 
context, but their project set serializer cannot *assume* that the context 
passed is indeed their own preferred context.  If it is not, then the serializer 
is required to gracefully degrade with the appropriate defaults.  Wherever 
possible the Team UI will request and use the preferred context for that 
provider type.

This approach should satisfy the need for a rich UI experience with that 
repository type and also the flexibility to drive the repository in a headless 
manner.

Proposed Implementation:

The method for returning a preferred UI based context for a project set 
operation does not belong in the Team core, but rather in the Team UI because it 
will have references to other UI components.

Assuming (please correct these if they are wrong)
1) extension points in the team core are slowly being consolidated into a single 
"repository" extension point and RepositoryProviderType subclasses, and that
2) the same sort of consolidation is or should be happening at the team UI level

Then it would stand to reason that 
1) there should be a "repositoryUI" extension point in the team UI parallel to 
"repository" extension point already existing in the team core, and that
2) there should be a "RepositoryProviderTypeUI" class in the team UI parallel to 
the "RepositoryProviderType" class in the team Core

Thus this new RepositoryProviderTypeUI class would contain a new 
getPreferredProjectSetSerializerContext() method so that provider specific 
subclasses could return their own *preferred* UI context.