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
Are these rules really the only ones? I seem top remember seeing a Policy in the class diagram that was doing something similar?
In any case, yes, this should live in the base plugin.


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

On further examination, the default rules currently reside in the ui plugin - in the wizard code - these should probably be refactored out of there?


From: tigerstripe-dev-bounces@xxxxxxxxxxx [mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard Craddock (rcraddoc)
Sent: 12 May 2008 15:44
To: Tigerstripe developers list
Subject: [tigerstripe-dev] Model Component naming Extension Point


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.
        Method Arguments ( see note below ).

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

 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 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.



tigerstripe-dev mailing list

Back to the top