[SLD] add limit violation highlight

[jamal-khey]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce?
feature:
This PR add a CSS class to Lines/Transformer/Bus in case of a limit violation

expected result, similar to what is done for NAD, we want to be able to highlight the equipment that has a limit violation
example 1
example 2

similar animation is also applied to busbarsection :

example 3

What is the current behavior?
the label is added but without informations if the equipment is in limit violation

What is the new behavior (if this is a feature change)?
add a CSS class sld-overload sld-vl-overvoltage sld-vl-undervoltage

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

Modifications in animations.css

[So-Fras]

Thank you for this PR. I have a few points that are unclear to me:

• Shouldn't we add the style in the .css?
• What kind of equipment could be overloaded? Here I am under the impression that a connectivityNode could be "overloaded". Does it make sense?
• I am not sure that we should modify the AbstractStyleProvider. We could do the same as what we did with the HighlightLineStateStyleProvider

To be further discussed!

[flo-dup]

Shouldn't we add the style in the .css?

Indeed, could you add the css from gridsuite/gridstudy-app#2244?

What kind of equipment could be overloaded? Here I am under the impression that a connectivityNode could be "overloaded". Does it make sense?

Indeed, I think overloaded is now everywhere in the graph, but we tried to avoid to populate the graph with data which is not needed for the diagram structure. The way we handle this is to look in the network when requesting the classes on a particular node or a particular edge, like in HighlightLineStateStyleProvider

I am not sure that we should modify the AbstractStyleProvider. We could do the same as what we did with the HighlightLineStateStyleProvider

Indeed, we'd rather do it like that

[flo-dup]

About the rendering, if we want to keep the same rendering as the connect / disconnect styles from HighlightLineStateStyleProvider, we should have only the last edge blinking, not the whole cell like in the unit tests. And if it's a transformer which is overloaded, shouldn't it be only the transformer which is blinking?

[jamal-khey]

Indeed, I think overloaded is now everywhere in the graph, but we tried to avoid to populate the graph with data which is not needed for the diagram structure. The way we handle this is to look in the network when requesting the classes on a particular node or a particular edge, like in HighlightLineStateStyleProvider

I reread the PR and realized that we did not fully address @flo-dup 's comment. What he means is that, if possible, we do not want to add the "isOverloaded" (or "isLimitExceeded") kind of information to the graph because it is not necessary to build it. The graph is about Node and Edge and we try not to include "power network" kind of information in it.

Yes you are right @So-Fras , i miss understood the comment.

When we had to do something similar to your PR in the past, we proceeded as in the HighlightLineStateStyleProvider. We linked the Node or Edge to equipment of the network and then we assessed the "state" of the Node or Edge. That is why the HighlightLineStateLineStyleProvider's constructor takes a Network as a parameter.

Could you try to do the same here? Else in the HighlightLineStateStyleProvider (but the name of the class should be changed) or in another specific StyleProvider (maybe better).

I have made the necessary changes to align with this approach, similar to the HighlightLineStateStyleProvider , i added LimitHighlightStyleProvider

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
93.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[So-Fras]

This PR fixes the #590 issue.