-
-
Notifications
You must be signed in to change notification settings - Fork 269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow multi-line names for objects #77
Comments
This is a great feature and obviously I'd like to see it included in Archi 3 as this would allow us to use Mastering ArchiMate naming convention. For my blog post I had to manually add spaces to break line before the "(Element Type)" part, ok for some views but not for a big model and associated report. |
The code is there. The question is this - should a name be short and then have an additional text that is longer. To be honest, all this does is allow you to put line breaks in the name. |
I'd like to see it included too. :-) |
should a name be short and then have an additional text that is longer This remembers me discussion that occured when you removed relationship's label and used name instead. Maybe we should have both a name and a label (allowing newlines), and just use name if label is empty. Next step would then be to allow some markup in label ({NAME}, {TYPE}, {PROP:propertyname}...), That would be awsome. |
Yes, I remember that. A lot of people voted to change that old behaviour so that the label = name. Many users thought an extra label was superfluous. For the Name + Label option - we have to think this through. What are the consequences of this? For example, when you direct edit the name (in tree or in figure) what are you editing? Name or label? Perhaps we could re-purpose the description field? Markup option - nice. Would depend on having a label option. As it stands, with this implementation, all we are doing is allowing line breaks in the name field. This doesn't break any existing behaviour and is backwards compatible. |
Created a new branch, "multiline-names". Feel free to try it out. But let's keep it simple for now, ok? :-) |
I ask myself some questions:
|
Back to the drawing board on this one. Branch is removed for now. |
Wouldn't it make more sense to allow users to choose which properties to display within elements? For example you could define a property "Pattern type" and display it's contents by setting a template: [{Archi_name}] The first and last line would be using "built in" types. The default template would then just be: {Archi_name} This would not overload the name for something it isn't and still have the benefits that we seek... |
Disappointing to see this issue open for so long - surely this cannot be a difficult thing to do? We are trying to adopt Archimate as a modelling language in our organisation, but our business stakeholders aren't impressed by some of the silly constraints in the models. How do we expedite this improvement? |
Sometimes a feature has deep dependencies.
Then perhaps this is not the right tool for you. Suggest you look at alternatives that don't have "silly constraints".
As this is open source, you can contribute the code, or perhaps consider contributing financially toward the implementation of this feature. |
Thanks.. I'll take a look. We are already compiling the business case for other alternatives. |
Hi, I just updated my specialization plugin to do it (the plugin allows to separate the concept labels from their names). I added this morning the 2 following updates:
Hope this helps |
That's awesome, Hevé! I'm trying to prototype/explore some things, and this functionality was preventing me showing stereotypes the way I wanted. The fact that it works based on variables is super slick. You saved my day! THANKS! |
you're welcome :) |
At the moment, all name attributes for an object are single-line. The name attribute is saved as a single line in the model, and the text editing components are single line.
Allow multi-line names, like the "Documentation" field.
The text was updated successfully, but these errors were encountered: