Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tigerstripe-dev] Model Component naming Extension Point

Title: Re: [tigerstripe-dev] Model Component naming Extension Point
Yes. It sounds like a global “Initial Name Service” for model components would make a lot of sense. This type of logic is currently distributed/replicated over the code in diagrams, wizards, editors, dialogs, etc...

A nice enhancement to log into Bugzilla for sure.

Eric

On 5/12/08 7:44 AM, "Richard Craddock (rcraddoc)" <rcraddoc@xxxxxxxxx> wrote:


All,

We have had a couple of bugs about the naming rules for new components. Some of the names being suggested seem a bit "specific" to me, so I have been looking at making an Extension Point for Naming of new ModelComponents as they are added to the model. The idea is that existing rules in the platform are left pretty generic, but users who want more sophisticated algorithms, different defaults etc, can implement rules as they wish through the extension point.

(We need to ensure that in the event of failure to provide a new name, the existing mechanisms are used).

 
Need to provide new names for :

   Artifact (of each type).
    Association Ends.
    Dependency Ends.
    Attributes.
    Literals.
    Methods.
        Method Arguments ( see note below ).


The *SAME* naming algorithm method should be called from :

Wizard
 Editor
 Diagram (D & D)
 Anywhere else we create components.

This may be the case now - I'm just not 100% certain!

In theory we can get to anything we need from an IModelComponent. eg for an Attribute, we can access the containing Artifact and thus make sure we are "unique"for that Artifact. For an Artifact we can access the Project to check for unique ness at that level, and so on.in the case of Association Ends, it needs to look at other ends on artifacts, etc . This means the Interface that has to be implemented by a naming extension can be kept very simple.

NOTE THAT Method Arguments are not IModelComponents in the current API - but will be in the EMF based metamodel. They will therefore have to be delayed.

Comments welcome.

 
Richard

 


_______________________________________________
tigerstripe-dev mailing list
tigerstripe-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev

Back to the top