[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [elk-dev] Meta Data Language
|
Moin moin!
See comments below. No comment means “I agree“.
Could someone create Issues for the decisions in this discussion? (I'm currently on vacation)
> - I don't think I really understand why we need the 'duplicated'
> keyword. As far as I understand it, adding that keyword adds our own
> Property constant for a layout option in the generated Properties class.
> This mostly seems to be relevant for when we change the default value of
> a property. How about this instead: We always generate our own
> properties. Thus, when we change default values, we don't need to change
> our algorithm's code to new property declarations since it already uses
> our own declarations anyway. If we declare an explicit default value,
> the generated code includes default value constants and uses those to
> initialize the generated properties. If we don't specify explicit
> values, the default value declared in the original Property is used. I
> think this would make it a bit easier to understand how everything works.
Sounds good. That would mean we would have to replace all existing references to LayoutOptions in the algorithms _and_ make sure they are not reintroduced while working on them.
> - I understand what it means for a layout option to be advanced,
> programmatic, or output option. What does it mean to be a global option?
That means it's not interpreted by a Layout algorithm, but by a Layout connector or the DiagramLayoutEngine.
> Minor Remarks
> - Generated Properties classes:
> - Don't adhere to four spaces for indentation (if there are formatter
> preferences for the meta data language, we should set them properly in
> the Oomph setup)
> - Fields should be "public static final" instead of "public final static"
> - File header comment does not adhere to standards
The Java code is generated by the Xbase code generator. It is possible to change things there, but I would avoid it unless absolutely necessary.
>> - How should we proceed with lower / upper bounds? For now I removed
>> those from the meta data. I am thinking about introducing a more general
>> approach of “graph validation”, which could be applied before any
>> algorithm is executed. My feeling is that it would be more useful to
>> throw an exception in this pre-layout phase instead of silently ignoring
>> negative spacing values. If the source of the wrong values is
>> programmatic, they should be fixed anyway. If the source is the UI
>> (Layout view), ideally we should mark the wrong values there so the user
>> gets an early feedback about nonsense configurations.
>
> My proposal would be two-fold. One, declare min/max bounds, if
> necessary, in the meta data language. This information can be used for
> the UI hints you mentioned. Second, have the meta language code generate
> a validateProperties(IPropertyHolder) method that can be called from the
> layout algorithm to throw an exception if bounds are invalid.
But if we check the bounds generically in the UI we need to store them in memory, so we could do the validation generically as well.
> property. What exactly the generated documentation will look like
> the subject of a subsequent discussion.
>
>
--
Dr. Miro Spönemann
Software Engineer
Telefon: +49 (0)431 99026 870
Mobil: +49 (0)151 426 794 59
itemis AG
Niederlassung Kiel
Am Germaniahafen 1
24143 Kiel
Rechtlicher Hinweis:
Sitz der Gesellschaft: Lünen
Amtsgericht: Dortmund HRB 20621, USt-IdNr. DE 23 11 77 498
Vorstand: Jens Wagener (Vorsitzender), Wolfgang Neuhaus, Sebastian Neus, Dr. Georg Pietrek, Jens Trompeter
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
