v15.2 - How to enhance "hardcoded" element shapescripts

[Paolo F Cantoni]

We now know that the Data Modeling elements and properties (such as table, column, FK etc.) are hardcoded.  We've tried redefining the metatype ("DBTbl" ... generalizes="EAUML::Table" baseStereotypes="EAUML::Table" redefines="EAUML::Table") but that seems to break the hardcoding.  However, we have found that by adding the EAUML::Table stereotype back into our item after creation, it restores the (hardcoded) table functionality (AND, especially from our point of view, allows the shapescript to access our extended properties)!  This, I presume, is a defect manifestation (that is, the redefines/generalizes/base stereotype is not working), but at least it's a workaround.

However, when we drag and drop a "DBTbl" from the toolbox (or even create a "DBTbl" element from the browser) we can only get a single stereotype value ("DBTbl").  How can I get a DBTbl toolbox item to create a t_object item with both <Profile>::DBTbl and EAUML::table stereotypes?

TIA,
Paolo

[Eve]

Unless I'm mistaken, the user guide for the redefines specifies that you need to use the same name.

Not that it matters, I have explicitly said here in the past that much of the DB modeling functionality within EA explicitly checks for the exact fully qualified stereotype name. ie. It explicitly does not check for inheritance.

The only way I can think of to add an element with two stereotypes from the toolbox is to create a pattern for that element type and add that pattern to the toolbox.

[Paolo F Cantoni]

Unless I'm mistaken, the user guide for the redefines specifies that you need to use the same name.

Not that it matters, I have explicitly said here in the past that much of the DB modelling functionality within EA explicitly checks for the exact fully qualified stereotype name. ie. It explicitly does not check for inheritance.

The only way I can think of to add an element with two stereotypes from the toolbox is to create a pattern for that element type and add that pattern to the toolbox.

OK, perhaps my bad.  We can live with the same name so long as the required shapecript is executed.  I'll confirm/deny the naming process.

Paolo

[Paolo F Cantoni]

Unless I'm mistaken, the user guide for the redefines specifies that you need to use the same name.

Not that it matters, I have explicitly said here in the past that much of the DB modeling functionality within EA explicitly checks for the exact fully qualified stereotype name. ie. It explicitly does not check for inheritance.

The only way I can think of to add an element with two stereotypes from the toolbox is to create a pattern for that element type and add that pattern to the toolbox.

I've NOW had a chance (time and resources permitting  ) to investigate this issue and come up with an architecture to meet our requirements.

Firstly, let me restate the requirement:
We wish to take advantage of the inbuilt (and hardcoded) Data Modelling functionality whilst allowing the use of a shapescript "overlay" that gives us more control over rendering.

Issues:
The functionality is hardcoded and therefore in order to make use of it, the appropriate EAUML::<stereotype> stereotype needs to be available to the item.

What we found:
As explained below, we tried to (manually) create an MDG entry:
("DBTbl" ... generalizes="EAUML::table" baseStereotypes="EAUML::table" redefines="EAUML::table")
as noted, we still had to add the EAUML::table in order to "restore" the required functionality.

Eve suggested that "DBTbl" needed to be renamed to "table", but that turned out NOT to be the case!  In fact, in typical EAUI fashion, this causes more problems than it solves!

Eventually, we found that the solution rested on having the EAUML::table as a secondary stereotype, and DBTbl as the primary stereotype AND removing ALL reference to EAUML::table in the DBTbl definition!

This suits us as we don't need to play "games" with the metamodel.  We couldn't work out how to create a redefines clause using the new metamodel - can some kind soul provide the answer (in case we need it for some other functionality?).

Now that we understand what is possible and how to do it we will implement processes to make these things as transparent to the user as we can.

Thoughts?
Paolo