Allow multi-line names for objects

[Phillipus]

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.

[jbsarrodie]

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.

[Phillipus]

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.

[Phillipus]

I'd like to see it included too. :-)

[jbsarrodie]

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.

[Phillipus]

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.

[Phillipus]

Created a new branch, "multiline-names". Feel free to try it out. But let's keep it simple for now, ok? :-)

[Phillipus]

I ask myself some questions:

• Are line breaks merely a display issue?
• What is an element "name"? Should it include the line breaks?
• Exported Jasper and HTML reports show the line breaks for the element name - should these be stripped of line-break characters when creating report?

[Phillipus]

Back to the drawing board on this one. Branch is removed for now.

[tuxwielder]

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}]
<<{Pattern type}>>
({Archi_Element_type})

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

[misterbotha]

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?

[Phillipus]

Disappointing to see this issue open for so long - surely this cannot be a difficult thing to do?

Sometimes a feature has deep dependencies.

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.

Then perhaps this is not the right tool for you. Suggest you look at alternatives that don't have "silly constraints".

How do we expedite this improvement?

As this is open source, you can contribute the code, or perhaps consider contributing financially toward the implementation of this feature.

[misterbotha]

Thanks.. I'll take a look. We are already compiling the business case for other alternatives.

[herve91]

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:

• Replace the "\n" string by a new line
• Expand variables ${name}, ${id}, ${property:xxxxx}, ... the same way my form plugin does

Hope this helps
Best regards
Hervé

[atownley]

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!

[herve91]

you're welcome :)