DrawIO: New Line in Transition

[timscheuermann]

When I add a transition with an Event and a condition from one state to another, i get different code generation results when i add a new line between the Event and the condition.
For example when adding the transition
EVENT_BUTTON_START_CLICKED [m_form.ValidFileSelected() >= 0] in only one line, the event and condition both gets inserted.
But when I do a linebreak the event is ignored and statesmith inserts a DO-Event instead, which seems wrong although nothing really has changed in the diagram except for the new line. This transition looks like this:
EVENT_BUTTON_START_CLICKED
[m_form.ValidFileSelected() >= 0]

As a workaround I insert the opening square bracket in the first line and the rest of the condition in the second line, which gives the expected result:
EVENT_BUTTON_START_CLICKED [
m_form.ValidFileSelected() >= 0]

Is this a bug or is there a better workaround? Because me as a user would not expect this behaviour.

[adamfk]

I think what's happening when there's a line break in between is that StateSmith sees them as two separate Behaviors sharing the same edge/arrow. One behavior is just your event, and the other behavior is just the guard. That's a feature that might need some changes. I'll do more investigation on my break/lunch today. Thanks for raising this issue.

…

On Wed., Nov. 27, 2024, 6:25 a.m. Tim Scheuermann, ***@***.***> wrote: When I add a transition with an Event and a condition from one state to another, i get different code generation results when i add a new line between the Event and the condition. For example when adding the transition EVENT_BUTTON_START_UPDATE_CLICKED [m_form.IEB900_ValidFileSelected() >= 0] in only one line, the event and condition both gets inserted. But when I do a linebreak the event is ignored and statesmith inserts a DO-Event instead, which seems wrong although nothing really has changed in the diagram except for the new line. This transition looks like this: EVENT_BUTTON_START_UPDATE_CLICKED [m_form.IEB900_ValidFileSelected() >= 0] As a workaround I insert the opening square bracket in the first line and the rest of the condition in the second line, which gives the expected result: EVENT_BUTTON_START_UPDATE_CLICKED [ m_form.IEB900_ValidFileSelected() >= 0] Is this a bug or is there a better workaround? Because me as a user would not expect this behaviour. — Reply to this email directly, view it on GitHub <#425>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACC4XDHLFSJAR3PZCLUCOT2CW225AVCNFSM6AAAAABSSXEAVCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGY4TQMZXGUYTEOA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[adamfk]

Hi @timscheuermann. This is currently by design although I'm open to suggestions to improve it. I know I've wanted to split up a long behavior string into multiple lines like you.

There are two use cases that are in conflict right now, but we can probably modify the grammar to satisfy both.

• Multiple Behaviors Sharing An Edge
• Guard Clause On Separate Line

Multiple Behaviors Sharing An Edge

Sometimes I have designs where I want multiple events or behaviors to share the same transition to keep the diagram uncluttered.

Below is a made up example. The left hand side shows the draw.io design and the right hand side shows the generated simulator.

Guard Clause On Separate Line

When you have long event names, it would be nice to be able to have the guard condition on a separate line from the event like below.

The current workaround that you list above isn't too bad.

Proposals

We can satisfy both by either adding to the grammar or changing the grammar. If possible, I would prefer to add to the grammar so that we don't break user's existing diagrams. But if we can't find a nice solution, we can modify the grammar. It is probably reasonably minor as I haven't documented the feature of Behaviors sharing a single edge here yet. I've been meaning to get to that #164.

P1 - Change Grammar For Behaviors Sharing Edge

StateSmith currently supports all 3 syntax below, but we could remove "SYNTAX 0" so that guards could be on a separate line from events. It would be a slight breaking change and I'd want to poll the discord group before starting to implement this change.

P2 - Add To Grammar To Support Line Breaks

We could keep the grammar as is and do something like supporting backslashes to continue a line. This is fairly common in a number of programming languages.

I'm currently not a giant fan of this approach. The UML syntax we follow already has a lot of special characters.

P3 - Leave As Is

Any other ideas?

Thoughts

I'm personally leaning towards P1. I'd like StateSmith to behave as users expect it to. The below syntax feels like it should be one behavior instead of two.

Your thoughts?

[timscheuermann]

First of all, I do not have big experience in Statesmith's behaviour on the different pattern.
My thought is to leave the behaviour as it is and adding a setting which allows the user to switch between multiple possibilities. The default setting would be the current behaviour. This means that all current diagrams will result in the same expected code. If the user wants other behaviour, he just changes it by changing the setting and its on him.

[adamfk]

This could work. It would also be nice to have a standard syntax though. Then I can look at any StateSmith diagram and not have to worry about the settings.

I'll scan through all the examples this weekend and see if I come across any places that would break. It might not actually affect anyone.