| 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
Attachment:
signature.asc
Description: OpenPGP digital signature