Archi Forum

Archi => General Archi Discussion => Topic started by: nfigay on September 05, 2021, 23:12:22 PM

Title: Labels using if and nvl
Post by: nfigay on September 05, 2021, 23:12:22 PM
Hello,
I'm looking exemples for usage of if and nvl as mentioned for Archi 4.9.
Available somewhere?
BR
Nicolas
Title: Re: Labels using if and nvl
Post by: Phil Beauvoir on September 06, 2021, 09:05:44 AM
Hi Nicolas,

I updated the wiki with some information on this - https://github.com/archimatetool/archi/wiki/Label-Expressions

This is something that JB very cleverly implemented. A good use case is to display an object's specialization name surrounded by angle brackets if it has one, else display nothing:

${if:${specialization}:<<${specialization}>>}

Regards,

Phil
Title: Re: Labels using if and nvl
Post by: nfigay on September 06, 2021, 11:11:22 AM
Thank you very much, Phil.
It is effectively a very useful features, thanks to Jean Sebastien Baptiste for having implemented it :)
Title: Re: Labels using if and nvl
Post by: rchevallier on September 08, 2021, 13:28:50 PM
Very interesting and useful indeed

However because 4.9 incompatibility with coArchi conflicts (as far I understood), we may have a longer time before adopting 4.9 (waiting then for coArchi v2)
Would it be possible to mark the 4.9 new features in the documentation with a tag or notice (eg: "@since 4.9") ?
Title: Re: Labels using if and nvl
Post by: Phil Beauvoir on September 08, 2021, 13:38:26 PM
Quote from: rchevallier on September 08, 2021, 13:28:50 PM
Very interesting and useful indeed

However because 4.9 incompatibility with coArchi conflicts (as far I understood), we may have a longer time before adopting 4.9 (waiting then for coArchi v2)
Would it be possible to mark the 4.9 new features in the documentation with a tag or notice (eg: "@since 4.9") ?

Yes, I've added "(Since 4.9)" for the three new label expressions in the wiki.

Archi 4.9 will still work with coArchi, but you won't be able to see the difference when merging if Specializations are used.

(I accidentally edited your message instead of quoting it. I've put it back to how it was  :D)
Title: Re: Labels using if and nvl
Post by: rchevallier on September 08, 2021, 15:07:56 PM
Thanks Phil et again great product !
Title: Re: Labels using if and nvl
Post by: kimh on September 13, 2021, 22:29:40 PM
Using Archi 4.8.1
I have tried for a while to use there 'if' expression but had no luck. The wiki defines a 'condition' but unsure of its syntax.
I have the following label:

${name}
${property:legacy}
${if: ${property:legacy}: (legacy)}

I want to display '(legacy)' if this property is set to 'true', otherwise it is missing. Or could be set to false.

With the above I get the following displayed:

Parts Service
true
${if: true: (legacy)}

Note the second line is only there to debug the value of the property. What I want is:

Parts Service
  (legacy)

Unclear if the syntax is correct, and then it would be good to test for property:legacy = false.

Thanks
Kim


Title: Re: Labels using if and nvl
Post by: Phil Beauvoir on September 13, 2021, 22:33:39 PM
Hi Kim,

the "if" expression is implemented in Archi 4.9 which is in beta at the moment.

The wiki does mention "Since 4.9" for this expression.

The condition is not true/false but whether the evaluated expression is an empty string or not.

Regards,

Phil
Title: Re: Labels using if and nvl
Post by: Alberto on September 14, 2021, 14:21:20 PM
QuoteThe condition is not true/false but whether the evaluated expression is an empty string or not.

I'm no programmer or philosopher, but wouldn't then "ifEmpty" or "isEmpty" be a more appropriate term for this function? 

At least it would be consistent with other languages that do have different functions for evaluating for empty/undefined/null vs logic. 
Title: Re: Labels using if and nvl
Post by: Phil Beauvoir on September 14, 2021, 14:38:14 PM
Quote from: Alberto on September 14, 2021, 14:21:20 PM
QuoteThe condition is not true/false but whether the evaluated expression is an empty string or not.

I'm no programmer or philosopher, but wouldn't then "ifEmpty" or "isEmpty" be a more appropriate term for this function? 

At least it would be consistent with other languages that do have different functions for evaluating for empty/undefined/null vs logic.

It would have to be "ifNotEmpty", but that seems rather long-winded.
Title: Re: Labels using if and nvl
Post by: Jean-Baptiste Sarrodie on September 14, 2021, 14:49:25 PM
Hi,

Jumping in...

Quote from: Phil Beauvoir on September 14, 2021, 14:38:14 PM
It would have to be "ifNotEmpty", but that seems rather long-winded.

Yes, that's the main reason.

Quote from: Phil Beauvoir on September 13, 2021, 22:33:39 PM
The condition is not true/false but whether the evaluated expression is an empty string or not.

It shouldn't be complicated to also make it consider "0" and "false" as false value. BTW, that's how StringTemplate works (primarily based on string being null/empty, but for the same reasons decided to also accept 0/false). In such case a string with only spaces should also be seen as empty.

@Phil: I can submit a patch if you want.

Regards,

JB
Title: Re: Labels using if and nvl
Post by: Phil Beauvoir on September 14, 2021, 14:56:03 PM
> @Phil: I can submit a patch if you want.

OK, but I think it would be easy to check for 0 and "false" so I might look at it. But...doesn't this negate the true meaning of "empty value"? Suppose someone sets 0 or false and wants the existing behaviour?
Title: Re: Labels using if and nvl
Post by: Jean-Baptiste Sarrodie on September 14, 2021, 16:07:43 PM
Hi,

Quote from: Phil Beauvoir on September 14, 2021, 14:56:03 PM
But...doesn't this negate the true meaning of "empty value"? Suppose someone sets 0 or false and wants the existing behaviour?

Well, until we publish Archi 4.9, there's no "existing behavior" :-)

TBH, while first thinking about this "if" expression, I thought it would be useful to also check for 0/false but simply didn't implement it.

I don't see much real life use-cases where someone would have "0" or "false" value somewhere and really want to know if this is empty or not (and "nvl" might still be helpful in this context). But I do see real life use-cases where someone has some "boolean" properties and want to adjust the label based on them.

Regards,

JB
Title: Re: Labels using if and nvl
Post by: Phil Beauvoir on September 14, 2021, 16:12:04 PM
Quote from: Jean-Baptiste Sarrodie on September 14, 2021, 16:07:43 PM
But I do see real life use-cases where someone has some "boolean" properties and want to adjust the label based on them.


Then they could leave the property blank?
Title: Re: Labels using if and nvl
Post by: Jean-Baptiste Sarrodie on September 14, 2021, 19:27:45 PM
Hi,

Quote from: Phil Beauvoir on September 14, 2021, 16:12:04 PM
Then they could leave the property blank?

That's not user friendly. For example, if I have a "Is Critical?" property on Application Components, then when publishing my model in HTML so that non architects can have access to it, seing such property name with no value is not an option as people expect to read yes/no or true/false.

Regards,

JB
Title: Re: Labels using if and nvl
Post by: kimh on September 15, 2021, 07:33:07 AM
My mistake with version above, but the use of the word 'since', made me think it was a past version, so did not check. Would not 'coming in 4.9' be clearer.

In regard to above issue with true, false and non existent. Logic languages like Prolog assume the Closed Worlds Assumption, that is if a piece of data does not exist then its false. For example, I have 3 cars in my garage. There is no Ferrari, so its false (in my world) that a Ferrari is Red.
So
IsCritical = false is the same as not stating isCritical. Things that are not known are false.
IsCritical = true is saying it is known as true.

So you can have  a very simple test syntax
IF IsCritical
THEN True Option
ELSE False Option

This is quite a valid approach in logic, but is very different to imperative programming languages. So I think its a safe approach for a diagraming tool.
Boolean values could be: yes/true/1,  no/false/0/non-existent

In my example above, I was wondering how to do this, and not stating the property Legacy = true means its false. I only need to state it when it's explicitly true, and this makes maintenance easy. If I do say its false then all good.

Title: Re: Labels using if and nvl
Post by: Phil Beauvoir on September 22, 2021, 14:33:32 PM
Quote from: Phil Beauvoir on September 08, 2021, 13:38:26 PM
Quote from: rchevallier on September 08, 2021, 13:28:50 PM
Very interesting and useful indeed

However because 4.9 incompatibility with coArchi conflicts (as far I understood), we may have a longer time before adopting 4.9 (waiting then for coArchi v2)
Would it be possible to mark the 4.9 new features in the documentation with a tag or notice (eg: "@since 4.9") ?

Yes, I've added "(Since 4.9)" for the three new label expressions in the wiki.

Archi 4.9 will still work with coArchi, but you won't be able to see the difference when merging if Specializations are used.

(I accidentally edited your message instead of quoting it. I've put it back to how it was  :D)

Actually, Archi 4.9 will not work with coArchi if there are Specializations in the model. We are investigating a fix. In the meantime don't add Specializations to models shared with coArchi!
Title: Re: Labels using if and nvl
Post by: rheward on May 26, 2023, 15:02:35 PM
Easy one for a Friday afternoon; so how do you test for a property value?

For example, I want a property called "Compliant" and this is going to be Yes or No.

I was thinking..

${name}
${if:(${property:Compliant}.match("Yes")):COMPLIANT:NONCOMPLIANT}

But that just proved I don't know how to use match. Or how to generate an empty return.
Title: Re: Labels using if and nvl
Post by: Jean-Baptiste Sarrodie on May 30, 2023, 13:45:06 PM
Hi,

Quote from: rheward on May 26, 2023, 15:02:35 PMI was thinking..

Code Select Expand
${name}
${if:(${property:Compliant}.match("Yes")):COMPLIANT:NONCOMPLIANT}

But that just proved I don't know how to use match. Or how to generate an empty return.

(Unfortunately) Label expression can't check the content of an information, only if it is null/empty or not.

Regards,

JB