Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: brback on October 15, 2016, 12:21:09 am
-
When modelling an element you will at times experience that the element name is too long to fit inside the element figure, the element name label will then extend beyond the figure borders. So far I have solved this manually by inserting a Space in the element name, which makes the element name fit inside the figure and easier to read in a diagram, but harder to read in the Project browser. For example the element name "TooLongElementNameDoesNotFitInFigure", I would manually break into "TooLongElementName- DoesNotFitInFigure", which will fit into the element figure but create an unwanted spacing for the element in the Project browser.
Does there exist a way for Sparx to automatically break such element names into several lines, so they will fit into the element figure?
-
Nope. You just can control wrapping of features with Feature Visibility/When Resizing. The element name is only wrapped when it contains spaces, hyphens, and eventually other special chars I'm not aware of.
q.
-
It could probably be done by adding aBreak Permitted Here (http://unicode-table.com/en/0082/) or Zero Width Space (http://unicode-table.com/en/200B/) character in the name.
But I'm not sure how to do that, and it will probably break code engineering (if it's being used) and copy and paste could behave weirdly.
Another alternative is to use a friendly/wrappable name as an alias, and show aliases on your diagram.
-
It could probably be done by adding aBreak Permitted Here (http://unicode-table.com/en/0082/) or Zero Width Space (http://unicode-table.com/en/200B/) character in the name.
But I'm not sure how to do that, and it will probably break code engineering (if it's being used) and copy and paste could behave weirdly.
Another alternative is to use a friendly/wrappable name as an alias, and show aliases on your diagram.
While the idea is seductive, "there be dragons..." It seems to me this would cause more problems than it fixes.
@brback is essentially asking for a solution to a rendering problem, not a naming problem
It seems to me that if a name uses both upper and lower case characters and NO spaces then it is (by definition) a Cased name. Using Convention over configuration, one can legitimately "wrap" at the interface between a lowercase character and an uppercase character (for left to right scripts).
@brback, you could submit a feature request and we could then support it.
Paolo
-
It seems to me that if a name uses both upper and lower case characters and NO spaces then it is (by definition) a Cased name. Using Convention over configuration, one can legitimately "wrap" at the interface between a lowercase character and an uppercase character (for left to right scripts).
Surely you mean camel-cased name (he says only in the interest of being accurate).
-
It seems to me that if a name uses both upper and lower case characters and NO spaces then it is (by definition) a Cased name. Using Convention over configuration, one can legitimately "wrap" at the interface between a lowercase character and an uppercase character (for left to right scripts).
Surely you mean camel-cased name (he says only in the interest of being accurate).
camel-cased is a insufficiently accurate name. We allow: Standard Camel Cased, Complex Camel Case, Standard Pascal Cased, Complex Pascal Cased names. The definition, in some sources, of camel case includes Pascal Cased (and also appears to have changed over the decades) and in other sources, they are related by quite distinct - so we use the more generic Cased Name to cover the "multitude of sins".
(in the "Standard" forms, acronyms and initialisms etc. are cased with uppercase first letter, the rest lower case, in "Complex" forms, the acronyms etc. are all in uppercase.)
HTH,
Paolo
-
camel-cased is a insufficiently accurate name. We allow: Standard Camel Cased, Complex Camel Case, Standard Pascal Cased, Complex Pascal Cased names. The definition, in some sources, of camel case includes Pascal Cased (and also appears to have changed over the decades) and in other sources, they are related by quite distinct - so we use the more generic Cased Name to cover the "multitude of sins".
Any proper noun is "cased", so your contraction seems to be unnecessarily ambiguous :-)
-
While the idea is seductive, "there be dragons..." It seems to me this would cause more problems than it fixes.
Absolutely. I mentioned two of the potential issues of the first approach. The second recommendation deals only with the rendering, but that in itself may be an issue in other places.
It seems to me that if a name uses both upper and lower case characters and NO spaces then it is (by definition) a Cased name. Using Convention over configuration, one can legitimately "wrap" at the interface between a lowercase character and an uppercase character (for left to right scripts).
I strongly disagree. This may be a rule that makes sense for a small subset of English speakers, but it certainly doesn't apply in general. EA uses Windows APIs to detect where it can wrap lines. I don't even know all the rules that they have to obey, but I know it depends on the language of the text.
PS. "Cased" seems so ambiguous as to mean nothing to someone who doesn't know your particular lexicon. "THIS TEXT" is upper case, "this text" is lower case, "This Text" is title case, "This text" is sentence case, "thisText" is camel case to me and "ThisText" is Pascal case to me. But they are all cased.
-
Taking distance from the intellectual masturbation around cased, camel, pascal or otherwise, it would seem a good idea to allow a break in long names whenever a lowercase-Uppercase difference is found.
ThatMakesSenseToMe
Geert
-
PS. "Cased" seems so ambiguous as to mean nothing to someone who doesn't know your particular lexicon. "THIS TEXT" is upper case, "this text" is lower case, "This Text" is title case, "This text" is sentence case, "thisText" is camel case to me and "ThisText" is Pascal case to me. But they are all cased.
Agreed, I should have said Cased Unspaced. The first three in your example are "spaced". The last two are unspaced.
And although EA uses Windows APIs to tell it where to break lines in text, names are not (narrative) "text", they are "tokens". The Windows APIs can happily apply to the Notes, they shouldn't apply to the Names. We are discussing the wrapping of tokens. Now the rules around wrapping of tokens and narrative text may have a large overlap, but they aren't the same.
All names in our repository are "tokenised", so that they may be compared correctly.
Paolo
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
I should have used cased unspaced
-
Taking distance from the intellectual masturbation around cased, camel, pascal or otherwise, it would seem a good idea to allow a break in long names whenever a lowercase-Uppercase difference is found.
ThatMakesSenseToMe
Geert
Gets my vote.... But not it needs to be the right transition:
ThatMakes
SenseToMe
Not:
ThatMakesS
enseToMe
Paolo
-
Lots of answers... thank you guys :)
Another alternative is to use a friendly/wrappable name as an alias, and show aliases on your diagram.
This seems to be the best solution for me at this moment, which I just found out there is an "Use Alias if Available" option for ;)
Taking distance from the intellectual masturbation around cased, camel, pascal or otherwise, it would seem a good idea to allow a break in long names whenever a lowercase-Uppercase difference is found.
ThatMakesSenseToMe
Geert
I agree, even though that was not part of my original intention. I used the lowercase-Uppercase difference only to make the word more readable in this example. Usually we would name an element "Thismakessensetome", but I guess it would be hard to break this without a dictionary or such. I would guess that this challenge is more prominent in my language (norwegian) as we tend to concatenate a lot of words that are splitted in english.
-
Which designates you to be a Donaudampfschiffahrtsgesellschaftskapitän. However, English is the lingua franca in the IT world. And what Geert said MakesAbsolutelySense. Instead of a complicated set of non-working rules I'd prefer a simple rule. Occam's razor cuts best!
q.
P.S. Obviously the wrapping is treated differently with labels: http://sparxsystems.com/forums/smf/index.php/topic,37288.0.html (http://sparxsystems.com/forums/smf/index.php/topic,37288.0.html)
-
Which designates you to be a Donaudampfschiffahrtsgesellschaftskapitän. However, English is the lingua franca in the IT world. And what Geert said MakesAbsolutelySense. Instead of a complicated set of non-working rules I'd prefer a simple rule. Occam's razor cuts best!
q.
P.S. Obviously the wrapping is treated differently with labels: http://sparxsystems.com/forums/smf/index.php/topic,37288.0.html (http://sparxsystems.com/forums/smf/index.php/topic,37288.0.html)
Interestingly, Google translate CAN'T translate Donaudampfschiffahrtsgesellschaftskapitän to English. But to Italian, it translates it as (English equivalent) Danube Steamship Company Captain - which to my very limited Gerglish seems right enough.
Paolo
-
When I said that it's following a lot of rules, it should be an implementation of http://www.unicode.org/reports/tr14/ (http://www.unicode.org/reports/tr14/).
I can't see anywhere that breaks tokens (or prevents then being broken) based on character case, but I wouldn't rule out that something like that could be happening inside the implementation. Besides the fact that the original question turns out to not be after it, that's why I don't think implementing a break at new camel case (general sense) word would be a good idea.
Usually we would name an element "Thismakessensetome", but I guess it would be hard to break this without a dictionary or such. I would guess that this challenge is more prominent in my language (norwegian) as we tend to concatenate a lot of words that are splitted in english.
Interesting.
The unicode line wrapping algorithm supports that option (as has been implemented by Microsoft) for South East Asian languages. Unfortunately, I don't see any way that we could implement that style of wrapping for you.
-
Probably no English speaker wants to talk to the captain of a Danube steamship ;D
German allows to assemble substantives almost at will. The captain is build from five different ones and you could easily add more.
q.
-
German allows to assemble substantives almost at will. The captain is build from five different ones and you could easily add more.
English allows compound words but there's a subconscious bias towards not mixing Greek, Latin, French, or old English (Germanic) derived words together.
-
Probably no English speaker wants to talk to the captain of a Danube steamship ;D
German allows to assemble substantives almost at will. The captain is build from five different ones and you could easily add more.
q.
Indeed! ;D
It seems to me however, that since (for English) the Unspaced Cased form is an artefact where even naturally lowercased words are "corrupted" for purposes of tokenising (ThisMakeSenseToMe), the same could be said of Germanic languages - Donaudampfschiffahrtsgesellschaftskapitän name would become the DonauDampfschiffahrtsGesellschaftsKapitän token.
I am assuming that such Germanic languages would wish to break tokens at sustantive boundaries.
Paolo
-
German allows to assemble substantives almost at will. The captain is build from five different ones and you could easily add more.
English allows compound words but there's a subconscious bias towards not mixing Greek, Latin, French, or old English (Germanic) derived words together.
Television being "an exception that proves the rule..." ;)
Paolo
-
German allows to assemble substantives almost at will. The captain is build from five different ones and you could easily add more.
In my youth, I visited Hamburg with a group of friends. We wanted to inspect and possibly rent a couple of rooms in a small hotel, but the hotelier took a dislike to us for any number of reasons - we were a group of boys and girls, some of us were English, some American, most of us spoke bad German or no German at all, some of us were not especially keen on the hotel in the first place... - and he thought he could get away with insulting us in German. However, one of our party was a Bavarian, who did not make his presence felt until the Hamburg Hotelier was well under way. The rest of us then got a fascinating lesson in 'assembling substantives' as the two of them swapped insults, taking deeper and deeper breaths in order to shout an ever increasing string of words at each other.
We didn't get to look at the rooms.
-
In my youth, I visited Hamburg with a group of friends. We wanted to inspect and possibly rent a couple of rooms in a small hotel, but the hotelier took a dislike to us for any number of reasons - we were a group of boys and girls, some of us were English, some American, most of us spoke bad German or no German at all, some of us were not especially keen on the hotel in the first place... - and he thought he could get away with insulting us in German. However, one of our party was a Bavarian, who did not make his presence felt until the Hamburg Hotelier was well under way. The rest of us then got a fascinating lesson in 'assembling substantives' as the two of them swapped insults, taking deeper and deeper breaths in order to shout an ever increasing string of words at each other.
Most Germans I've met tell you that Bavarians aren't Germans. All the Bavarians I've met have been friendly chaps; good to have a beer with.
-
Many (most?) Bavarians tell they are Bavarians, not necessarily Germans and they want to be independent (Bavexit; at least since they have to pay more than they formerly got from the state union). I guess the Bavarian won in the insult contest. They can get down to a grunt of vowels you can smell it's something you don't want to know in detail.
q.
-
It seems to me that when the "algorithmic approach" breaks down when it comes to breaking long tokens (which are found in IT) there are two further approaches
1) simply break it at an arbitrary point, e.g. halfway, to enable the string to wrap
2) allow the (human) author to provide guidance (e.g. a hard return) that is ignored (or held separately) on where to split the token.
-
I'd prefer 2 and would not like to see 1. Arbitrary breaks could lead to awkward names. E.g if you split the German word Urinstinkt - meaning basic instinct - like Urin stinkt it would mean pee stinks. Not a long word, but a good example for "breaking bad".
q.
-
The algorithmic approach (http://www.unicode.org/reports/tr14/) already provides for option 2.
Insert a zero width space (http://www.fileformat.info/info/unicode/char/200b/browsertest.htm) into the text.
-
The algorithmic approach (http://www.unicode.org/reports/tr14/) already provides for option 2.
Insert a zero width space (http://www.fileformat.info/info/unicode/char/200b/browsertest.htm) into the text.
Great, thanks
Now if I could do this easily from within the EA UI ...
or find it documented in the EA user guide
-
The algorithmic approach (http://www.unicode.org/reports/tr14/) already provides for option 2.
Insert a zero width space (http://www.fileformat.info/info/unicode/char/200b/browsertest.htm) into the text.
Simon,
What does this do to searches? Particularly the Project Search?
Paolo
-
skiwi,
Now if I could do this easily from within the EA UI ...
You want us to re-invent a unicode character entry system that should exist as part of your OS?
or find it documented in the EA user guide
And document the unicode standard within our user guide?
What does this do to searches? Particularly the Project Search?
It's an extra character where you've used it. You would have to include that in your search term if you wanted to find elements using it.
-
[SNIP]
What does this do to searches? Particularly the Project Search?
It's an extra character where you've used it. You would have to include that in your search term if you wanted to find elements using it.
Hence why it won't work... I think I tested this, years ago.
What's the odds of an option to remove the zero width space (ZWS) for search purposes?
Obviously, in an enterprise environment, one user can't "see" where another user has placed the ZWS.
So, ultimately the solution - isn't.
Paolo
-
Okay, what I should have said was that search depends on the collation settings for the database being used. You can already see this effect where searching will be case-sensitive or case-insensitive depending on the database collation.
I couldn't find evidence that any databases allow customization of the collation (or a collation that ignores zero width space,) but it's possible. Maybe there's another character in the unicode standard that is considered a possible line break point and is ignored in a standard collation type.
I don't think it's a perfect solution. But as far as I can see, it's the only solution offered by the unicode standard.
PS. I don't think an option to ignore that character in the search could work. It would require either doing the replace in SQL to compare with the search term. On any non-trivial database you'll be in a lot of trouble if you even try that.
-
Simon, I didn't say it was easy... ;D
However, it's got me thinking. Why not allow a special tagged value that defines the breaks (using, for example, ZWS - but I think it would be better if the break was visible. If the TV was present, EA could use that for the name.
We already have multiple name Tagged Values which can be selected with User Selected Diagram Properties. I should try the ZWS with those.
Paolo
-
You want us to re-invent a unicode character entry system that should exist as part of your OS?
And document the unicode standard within our user guide?
What I had I mind was:
Providing documentation in the EA user guide that indicated how a user could suggest to EA where to break long tokens (cf breaking hyphens), and maybe explain how EA does it algorithmically now.
Providing extra assistance to users by way of the UI so that:- users could easily create or remove a 'break suggestion'
- users could easily see where the suggested break might be, e.g. ⏎"⏎"
- the break suggestion would not impact searches, or use of names in other contexts, e.g. code generation (i.e. the break would not be part of the token)