Community
Participate
Working Groups
Replace logical name with physical name for test assets. Test assets (or more accurately, their resources) have a logical name and physical name, which may be different causing confusion with users. Regarding the benefit (if any) of the logical name for a test asset and determine if it could can be the same as the physical name, the logical resource name was created since all test resources extend from a common EMF class called org.eclipse.hyades.models.common.common.CMNNamedElement.java with ID, name, and description properties. There is no tangible benefit to keeping separate logical and physical names. The logical name can be replaced by the physical name by overriding the getName() to resolve the physical name of the resource and updating all of the editors to not allow the user edit the name of the resource (e.g. read-only).
I am not sure wha tis being proposed here since there are a lot of assertions in the description. It is pretty common practice to give artifacts logical and physical names in order to separate file and location names from the name a user wants to use. This is very useful in move and rename operations that affect references etc.. Defaulting them to be the same, or perhaps hiding physical names from normal user action is one thing but this seems to assert there is no value at all. Since this is a "bug"zilla, what problem is being solved.
(In reply to comment #1) > I am not sure wha tis being proposed here since there are a lot of assertions > in the description. > > It is pretty common practice to give artifacts logical and physical names in > order to separate file and location names from the name a user wants to use. > This is very useful in move and rename operations that affect references etc.. > Defaulting them to be the same, or perhaps hiding physical names from normal > user action is one thing but this seems to assert there is no value at all. > > Since this is a "bug"zilla, what problem is being solved. > The problem is an usability issue. From a user perspective, it is confusing that test assets (for example, test suites) have two names. As part of the work for enhancement 166025, we are considering the opportunity to reduce this confusion and simplify several of the use cases. Of course, we need to verify the impact of this change on our consumers and broader user community.
Kent, does your consuming product require logical names for test assets?
> The problem is an usability issue. From a user perspective, it is confusing > that test assets (for example, test suites) have two names. As part of the > work for enhancement 166025, we are considering the opportunity to reduce this > confusion and simplify several of the use cases. Of course, we need to verify > the impact of this change on our consumers and broader user community. > This is not just about consuming products, it is about changing the design and intended behavior/features of the model. As I noted there is a very specific reason to have the two ways of referencing the object. In fact there is good argument that the logical name is the one the user should always see. If there is a desire to not expose both names all the time, then perhaps consider a preferences to extension configuration to suppress either of them. But overriding the code makes the dual name feature meaningless.
(In reply to comment #4) > This is not just about consuming products, it is about changing the design and > intended behavior/features of the model. As I noted there is a very specific > reason to have the two ways of referencing the object. In fact there is good > argument that the logical name is the one the user should always see. If there > is a desire to not expose both names all the time, then perhaps consider a > preferences to extension configuration to suppress either of them. But > overriding the code makes the dual name feature meaningless. Agreed. A preference will be provided under defect 160485 to allow the user to select between displaying the logical (default) or file name of a test asset in the Test Perspective, views, wizards, dialogs, etc..
Closing.
