Manage abstract and class methods

[palra]

I just discovered your tool, awesome work ! It helps me a lot 👍
Something that is missing to me, that's just a very little point, but when I write

[Class||
  <abstract> + myMethod()
]

I'm actually expecting that the method is going to be written in italic, but that's not the case. In fact, the parser just does not take in account the type of the method. The same would be great for class methods and class attributes, but I don't know if a <class> classifier would be theright thing to do.

I'll be glad to help, but actually I'm a bit lost in those files, I'll probably take a deeper look at the code, so I can contribute to the project 😃

[skanaar]

Thank you 😊

I try to support as much of the UML standard as possible - something which is in conflict with the drive to keep the syntax as straight-forward as possible. I guess this part of the standard sort of fell on the wrong side of that line.

I value the universality of UML. The concept of Types with Relations can be applied to pretty much anything. Parts of the standard that relates to specifics of some languages, such as the concept of an abstract method or template type parameters are much less universal. I will not dismiss the idea completely but I would not prioritize abstract method formatting.

[palra]

So, what can be done in order to render the method underlined or in italic ? I should use the directives, but I didn't understood how to use them.

[skanaar]

Ah, sorry. It is not supported.
The directives affect the entire diagram, in a last-one-wins fashion. And classifier types abstract are only processed when they appear right after a [ and they affect the styling of the entire classifier.

If this is a much requested feature perhaps someone out there would like to submit a pull request?

[chishaku]

Perhaps it's helpful to break this problem down into smaller components.

1. Allow attributes and methods to be classified within a parent classifier
2. Allow custom and arbitrary styling within a parent classifier

The second part regarding more granular control over styling is probably in the same scope of #11.

I'm partial to the simplicity and universality of the current syntax but I could see myself wanting to modify styles within a classifier.