Feature request: ability to view values of the properties, generated by text labels (add a column "Value" )

[startsevsa]

In properties Tab:

1. current clumn 'Value' rename to 'Formula'
2. add column 'Value' (calculated by text label expressions in column firmula)

In HTML export show only property values (at this time the text labels are shown).

If the formula contains no label-expressions, then value is equal to formula text

[Phillipus]

Please provide more details, use cases, etc. Not sure what you mean by "add a column 'Value'".

[startsevsa]

[startsevsa]

The problem is that when I use complicated formulas in propertis with links between archomate concepts and folders and so on - I can't see the values of the properties for descendant object in the properties list (only when using them on labels for the current view).

[Phillipus]

I can understand wanting to preview the result of an expression for convenience, but I don't think renaming the existing "Value" column is a good idea in case there are no label expressions used.

[startsevsa]

I can understand wanting to preview the result of an expression for convenience, but I don't think renaming the existing "Value" column is a good idea in case there are no label expressions used.

the name of the column is not principal. You may call the new column 'Preview' (and it will be the same as Value if there are no expressions). But important thing IMHO is that when exporting to HTML (where label-expressions are not working) better change the text of 'Value' to 'Preview' text. Because in HTML or other report there is no need for the formula - but it is frequently needed to see the calculated value of the property.

[startsevsa]

As for example, in MS Visio there are two view types for the object property - value view and formula view:

[Phillipus]

To summarise the feature request:

1. Preview the computed value of a label expression in a Property (if there is one) somewhere in the table
2. Substitute the computed value of a label expression in a Property's value when generating reports (HTML, Jasper)

We can think about these, and perhaps consider them for the next time we update the Label Expressions feature (perhaps for Archi 4.8).

[jbsarrodie]

Hi, jumping on this...

What's the exact need behind? (for me, "being able to define properties through expression" is not a need, it is already a solution for a need I know nothing about).

We can think about these, and perhaps consider them for the next time we update the Label Expressions feature (perhaps for Archi 4.8).

We first have to be clear about the goal and use-cases. For me this is not really related to label expression but more with having typed properties with a type being "formula". But again, use-case should come first...

[startsevsa]

Hi, jumping on this...

What's the exact need behind? (for me, "being able to define properties through expression" is not a need, it is already a solution for a need I know nothing about).

We can think about these, and perhaps consider them for the next time we update the Label Expressions feature (perhaps for Archi 4.8).

We first have to be clear about the goal and use-cases. For me this is not really related to label expression but more with having typed properties with a type being "formula". But again, use-case should come first...

Goal is to put data in one place and use in many. For example, I want to see parent's (device) properties in the child object (interface).

[Phillipus]

It seems there are two requirements.

This:

The problem is that when I use complicated formulas in propertis with links between archomate concepts and folders and so on - I can't see the values of the properties for descendant object in the properties list (only when using them on labels for the current view).

To be able to preview the rendered label expression for convenience (perhaps a tooltip when hovering over the expression)

And this:

But important thing IMHO is that when exporting to HTML (where label-expressions are not working) better change the text of 'Value' to 'Preview' text. Because in HTML or other report there is no need for the formula - but it is frequently needed to see the calculated value of the property.

Which is, as JB says is:

being able to define properties through expression having typed properties with a type being "formula".

[startsevsa]

What's the exact need behind?

Need is to be able to see values not only after putting them into view

[startsevsa]

Which is, as JB says is:

being able to define properties through expression having typed properties with a type being "formula".

properties are already defined by formulas - so why not to say B, when sad A ? :-)

[Phillipus]

The original intent of this feature was to provide a means to display alternate text in labels in objects in Views and in the Models Tree. Expressions in Properties were intended to support this visual feature, not to behave like "labels" themselves or, as JB puts it, not intended to "being able to define properties through expression".

[startsevsa]

The original intent of this feature was to provide a means to display alternate text in labels in objects in Views and in the Models Tree. Expressions in Properties were intended to support this visual feature, not to behave like "labels" themselves or, as JB puts it, not intended to "being able to define properties through expression".

But all the visual alternative text is build of "labels" which are not abstract and has logical and physical meaning. This is why it is nessesary to have an option to model them not only visual - so to have a real model, whith which you can fully operate through model tree, but not only through visual schemas.

[startsevsa]

Example - I have a node and I need to move it from one device to another. And I have a property 'IP' which is derived from the parent object (device) by the child (node). So, I whant to see in other diagrams an IP of the node (according to a new device) even if there is no parent device on the diagram.

[startsevsa]

Further it goes to the autonaming of the object in model tree using text label expressions... but offcouse this is for discussion

[Phillipus]

These kinds of changes can have a bigger impact than one expects.

Just some thoughts off the top of my head...

• What about users who expect to see the literal property value when viewed in reports, jArchi, etc?
• And does that mean the model would need a new property field for the "rendered" value?
• When using properties in jArchi, in HTML Report, in Jasper reports and so on should this be an option when creating output (rendered or literal)? And if it is an option where is it? How does this affect the report ACLI (Archi Command Line Interface) options?
• The HTML report would require the frame.stg updated to account for this. Who will do that?

So, at the very least, this is not something to rush into without some impact analysis.

[startsevsa]

These kinds of changes can have a bigger impact than one expects.

Just some thoughts off the top of my head...

This is why I suggest to use a new field for the formulas, and use Value only as values, which are recalculated in case of formula field was filled. In this case all dependent code will use the "rendered" value, and only Archi wil render it "online".

My idea comes from this 2 points:

1. formulas in properties are excelent and "must have" feature, that is very helpful in everyday same operations
2. external tools (like HTML Reports, JasperReports, jArchi and so on doesn't need formulas - they need only values - because they don't and can't have the same render technology, as Archi)

[startsevsa]

Going further - another idea is to use conditional formating according to properties values (for inplementation example you can look at yEdGraph and Visio).