V15.2 - Stereotype rendering discrepancy - what's going on? EAUI!!!

[Paolo F Cantoni]

As we know, to get a stereotype applied correctly to an item (assuming the type is already correct), we need to update two properties:
The Stereotype field and the StereotypeEx field in the API and the equivalent t_object.Stereotype and t_xref.Description columns in the database.

In a recent post (v15.2 - DB Builder to allow EAUML::<component> as non-primary stereotype), I noted that we had "successfully" managed to get EA to apply both the EA specific EAUML::<Component> stereotype and our own stereotype to supply our overlaid rendering.  For example, our Database View stereotype should end up as: 

Code: [Select]

@STEREO;Name=DBVw;FQName=<our Profile>::DBVw;@ENDSTEREO;@STEREO;Name=view;FQName=EAUML::view;@ENDSTEREO; in t_xref.Description

In our toolboxes, we place our own stereotypes rather than the EAUML ones.

We do a lot of processing "behind the scenes" using direct SQL manipulation of the DB.  So for example, when the user drags our database item from the toolbox, it can only create a single stereotype entry in t_xref.Description (in this case:

Code: [Select]

@STEREO;Name=DBVw;FQName=<our Profile>::DBVw;@ENDSTEREO;)

So we run a query to fix it for the users and append the EAUML portion of the full t_xref.Description.

Imagine our surprise when the DBVw elements stopped using our shapescript AND MDG specified rendering!

Interestingly, some retained the rendering.  Comparing the ones with and the ones without via the UI we couldn't see any difference in the properties!

Surprise turned into consternation WT* is going on?  We compared the DB entries and again could see no discernable difference!

After a few frustrating hours, this morning we tumbled to the problem!

The one that "worked" had the entry:

Code: [Select]

@STEREO;Name=DBVw;FQName=<our Profile>::DBVw;@ENDSTEREO;@STEREO;Name=view;FQName=EAUML::view;@ENDSTEREO;And the ones that didn't had the entry:

Code: [Select]

@STEREO;Name=DBVw;FQName=<our Profile>::DBvw;@ENDSTEREO;@STEREO;Name=view;FQName=EAUML::view;@ENDSTEREO;
Can't see the difference?  Now you can appreciate the problem!  Especially since the UI showed identical output!!!

To be continued...  See if you can spot the difference before I post the next episode!
Paolo

[Geert Bellekens]

Found it.

"DBVw" vs "DBvw"

Geert

[Paolo F Cantoni]

Found it.

"DBVw" vs "DBvw"

Geert

Correct, Geert!   (admit it's easy once I "serve it up on a plate") 

But in the immortal words of those "blaring ads" on TV - But wait, there's more!

Can you guess what the UI showed when the FQN was DBvw?  Don't forget there's the stereotype in rectangular mode and the stereotype in the Properties window (and the properties dialog).  Note, in all cases, the t_object Stereotype was set to DBVw.

Paolo

[Geert Bellekens]

I wouldn't know.

What I do know is that some parts of EA are case sensitive with regards to the stereotype, and other parts aren't.
That probably why you are mixed results.

Geert

[Paolo F Cantoni]

I wouldn't know.

What I do know is that some parts of EA are case sensitive with regards to the stereotype, and other parts aren't.
That probably why you are mixed results.

Geert

(my emphasis)
In all cases, it showed DBVw (regardless of the state of the FQN).  So you can see why we were stumped for a long time!  It seems ONLY the FQN is affected in the t_xref.Description for control of the shapescript and MDG rendering.  We found that the diagram object displays the value of the Non-FQN name as the visible stereotype, BUT displays the value of the t_object.Stereotype in the Element Properties dialog, WHEREAS the Properties Window seems to show the unprofiled name from the MDG File!
(Tested with

Code: [Select]

  t_object.Stereotype = Dbvw, t_xref.Description = @STEREO;Name=DBvW;FQName=<profile>::DBvw;@ENDSTEREO; -  MDG profile stereotype = "DBVw")

Sparxians, Concistency, konsistency, consistensy! ^TM_{Uffe - after Paolo}, Please!!!


PURE EAUI!!!

Reported,
Paolo

[qwerty]

Get used to it. You won't see a fix. Stereotype handling is just insane. Take alone at the dropdown that lists "something" in *any* order which only a Sparxian may understand. Not talking about the stereotype of everything being in t_xref (i.e. under the rug) and diagram stereotypes ending up in t_diagram.style<something>. The stereotype and stereotypeEx which violate the principal of the least astonishment in the best manner.

q.

[Ian Mitchell]

I've come across similar issues with stereotypes. As with you, my work-arounds are getting more and more exotic.
Apart from the annoyance, this perhaps shows up a larger issue.

As we EA-nerds create ever-smarter ways to code around these (small) inconsistencies, we need to be careful what we wish for:
(a) If Sparx fix the issue, we have to change lots of our code, and potentially we get other bad side effects as a result of our previous cleverness
(b) If Sparx don't fix the issue, we keep writing lots more code to get around the other little annoyances we find.

So what do we want Sparx to do? (a) or (b)?
(And BTW Q - there is no (c) which is 'don't have the problem in the first place' - we are where we are. With a >10 year old schema and API - but scripts and addins which still work after all this time - we must expect this.)

I propose we call this "Paolo's Dilemma'.

[Geert Bellekens]

In this particular case I'm not sure if they really need to change anything.

The current behavior partially manages to resolve the stereotype although there is an error in the t_xref (lowercase vs uppercase)

From my point of view there is little to no reason to resolve the stereotype in case there is an error in t_xref, since that is controlled completely by the application and thus can be expected to be without error.
So the only sensible way to make the behavior consistent is to not resolve the stereotype anymore at all.

This might not be ideal for those of us who where a wrote code to edit the t_xref directly, but did so in an incorrect way (e.g. used the wrong case).
Me personally I would prefer EA to never try to resolve stereotypes anymore (with the off-chance of having it wrong), even if that means I need to rewrite some of my code.

Geert

[Paolo F Cantoni]

In this particular case, I'm not sure if they really need to change anything.

The current behavior partially manages to resolve the stereotype although there is an error in the t_xref (lowercase vs uppercase)

From my point of view, there is little to no reason to resolve the stereotype in case there is an error in t_xref since that is controlled completely by the application and thus can be expected to be without error.
So the only sensible way to make the behavior consistent is to not resolve the stereotype anymore at all.

This might not be ideal for those of us who wrote code to edit the t_xref directly, but did so in an incorrect way (e.g. used the wrong case).
Me personally I would prefer EA to never try to resolve stereotypes anymore (with the off-chance of having it wrong), even if that means I need to rewrite some of my code.

Geert

For the record, the incorrect case crept in because of a human error (I wrote an action query and miss-spelled one of the names).  The automated processes work properly for us.

I agree, that if Sparx did nothing, then (in this case) it wouldn't be the end of the world.  However, I AM concerned that the GUI in the Properties Window doesn't take into account the ACTUAL value of either t_object.Stereotype NOR the actual value of the t_xref.Description but INSTEAD uses the MDG stereotype name!

The main reason for putting n the defect request was to alert others that weird effects can happen when you don't get the casing right.

Paolo