Yeah, I’ve been on the other side of that, being the programmer working with the designer. So I agree, code is code, layout is layout.
As for what Yaml looks like, you’re right, the examples are lame. So this is a complex example in “flow” style, with the “pretty flow” option I added to SnakeYaml. It’s the first half of a file, so there are terminators missing. This is from our actual code.
Yaml has two flavors:
Block: Kind of like Python, indentation/whitespace is important to indicate nesting
Flow: whitespace is irrelvant, instead surround lists and { } surround name-value pairs, and there’s commas to terminate things.
For Pretty Flow, I take the indentation from Block and add {} and . But the indentation doesn’t matter, its just there to make it more readable. You have to make sure that your
and {} match, and you need commas here and there.
Note that # marks comments.
First the code:
# a series of steps
[
{ # begin step
title : "Step 1 of 1",
shortHelp : "This is some short help text for step 1",
popupHelp : "This is longer popup help text for step 1",
# begin a series of panels
panels : [
{ # panel start
title : "Panel 1",
shortHelp : "Short help text for panel 1 step 1",
popupHelp : "Popup help text for panel 1 step 1",
attributes : [
{ # attribute start
name : "emailAddress",
label : "emailAddress",
type : "String", # This is just for reference, we pull this from the model each time
# class : "BASIC", # This is just for reference, we pull this from the model each time
shortHelp: "",
popupHelp: "",
}, #end of an attribute
{ # attribute start
name : "uuid",
label : "uuid",
type : "String", # This is just for reference, we pull this from the model each time
# class : "BASIC", # This is just for reference, we pull this from the model each time
shortHelp: "",
popupHelp: "",
disabled: true,
}, #end of an attribute
{ # attribute start
name : "party?.name",
label : "Party",
type : "Party", # This is just for reference, we pull this from the model each time
# class : "MANY_TO_ONE", # This is just for reference, we pull this from the model each time
shortHelp: "",
popupHelp: "",
}, #end of an attribute
], #end of all attributes for panel
}, # end of a panel
There’s one thing that’s missing from this example, because this example doesn’t need it, and that is specifying any data types. The reason my above sample doesn’t have it is because SnakeYaml can determine from the context that a List has to be filled with objects of type “Foo”, and if you have an object “Bar” that has a parameter “color” of type “Color”, that it needs to build a “Color” object. Simple types like String, Integer, date can be inferred from the format of the data.
That is, if the type of an object can be determined from the context, either from the specification on the collection class or via the type of the object property, it’s not necessary to specify the type.
In the above, When I parse the file, I tell Yaml its parsing a List. Step.panels is set to be a List, and Panel has Panel.attributes = Map<String,Object>. Those are just the regular declarations for my objects, I didn’t add anything to be able to read/write the yaml!
If specifying the type is necessary, it looks like this:
!!com.example.ProductType {
guid: 3520D0F5-C2F1-49AB-8F43-F5C808F59D1F,
name: Demo Auth 9
},
That excerpt above is from a List, so Yaml knows that they’re all SuperType objects, but it doesn’t know which kind, so it has to specify the type.
Do you think you could work with that?
