Tigerstripe Custom Naming Rules

< To: Tigerstripe Extension Points

• Full name : org.eclipse.tigerstripe.workbench.base.customComponentNaming

Purpose : The workbench contains some default mechansisms that privide basic names for new model componenets - eg Artifacts, Fields, Methods etc. This extension point enables the definition of rules to override any or all of those default names. These names are used when new elements are created from the wizards, from editors and from class diagrams. The same mechanism is used in all cases.

• Usage :

There should only be one implementation of this extension point in any install. If there are more than one, then only the last one discovered will be used.

The extension point has two attributes - a "name" - which is used for logging only, and "namingClass" which must implement the org.eclipse.tigerstripe.workbench.model.IComponentNameProvider interface.

This interface has a number of methods whose names should be fairly self-explanatory :

 getNewArtifactName(Class artifactClass, ITigerstripeModelProject project, String packageName);
 getNewFieldName(IAbstractArtifact artifact);
 getNewLiteralName(IAbstractArtifact artifact);
 getNewMethodName(IAbstractArtifact artifact);
 getNewArgumentName(IMethod method);
 getNewAssociationEndName(IAbstractArtifact artifact, int whichEnd);

All of these return a String which will be used as the new component name. If a null is returned by any method, then the built-in default will be used (this allows users to just override one type of name if that is all that is required).

The arguments to these methods generally define the "scope" within which the name will be used, and can be used to ensure uniqueness, to add a count to the new component name etc. In the case of Fields, Literals and methods this is simply the artifact to which the new component will be added. Similarly for AssociationEnds, but with the addition of an integer to indicate if the A or Z end is being created. Argumenst take i the Method to which they are being added.

Artifacts are slightly more complex - they take in the Class of the artifact for which the name is to be created, the Project - which can be used to extract existing artifacts - and finally the packageName of the package where the artifact is to be added - which can also be used to limit the scope of uniqueness. In many situations you may allow duplicate artifact names, just not in the same package. (Note that the default provider does not use this argument value).

Internally the Name Provider uses the Factory pattern, so the same instance of your Custom Name Provider will be used for all names in your session.This may influence your design.

Example :

This example creates a new argument name using the ARGUMENT static, and increments the suffix according to the number of arguments that already exist on that method, then ensures that the argument name is not a duplicate.

   public String getNewArgumentName( IMethod method){
       Collection<IArgument> existingArguments = method.getArguments();
       int count = existingArguments.size();	
       String newName = ARGUMENT+count;
       // make sure we're not creating a duplicate
       boolean ok ;
           do {
               ok = true;
               for (IArgument exists : existingArguments){
                   if (exists.getName().equals(newName)){
                       count++;
                       newName = ARGUMENT+count;
                       ok = false;
                       break ;
                   }
               }
           } 
           while ( ! ok);
       return newName;
   }