| Re: [elk-dev] Meta Data Language |
Greetings!
On 09/02/16 00:00, Spönemann, Miro wrote:
> Could someone create Issues for the decisions in this discussion? (I'm
> currently on vacation)
Will do. :)
>> - 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.
True. I propose to do that once we've finished migrating all changes
over to ELK that have happened in KIELER in the meantime. There'll be
enough merge conflicts as it is already. ;)
https://github.com/eclipse/elk/issues/9
>> - 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.
Ah, I see. I feel like "global" is a bit misleading there. How about
"nolayout", "infra", or something like that?
>> 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.
Well, it is generated code which the programmer often enough won't look
at, so I guess we'll just spare us the hassle.
>> 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.
Agreed. No need for a custom, layout algorithm-specific method there.
The question is whether we want this kind of validation or not. Ulf,
what's your opinion on the new proposal?
Cheers,
Christoph Daniel
_______________________________________________
elk-dev mailing list
elk-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/elk-dev