tidy yaml ref docs
Project: http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/repo Commit: http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/commit/bf66d3ec Tree: http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/tree/bf66d3ec Diff: http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/diff/bf66d3ec Branch: refs/heads/master Commit: bf66d3ec9e8c9423b7552650f5168fb5af9245a1 Parents: 8591999 Author: Alex Heneveld <[email protected]> Authored: Fri Apr 10 12:31:16 2015 +0100 Committer: Alex Heneveld <[email protected]> Committed: Sun Apr 12 20:00:53 2015 -0500 ---------------------------------------------------------------------- docs/guide/yaml/yaml-reference.md | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/bf66d3ec/docs/guide/yaml/yaml-reference.md ---------------------------------------------------------------------- diff --git a/docs/guide/yaml/yaml-reference.md b/docs/guide/yaml/yaml-reference.md index 8427b06..07fffc9 100644 --- a/docs/guide/yaml/yaml-reference.md +++ b/docs/guide/yaml/yaml-reference.md @@ -10,7 +10,7 @@ layout: website-normal * `location` (or `locations` taking a list): a `LocationSpecification` element as a string or a map -## `ServiceSpecification` Elements +## Service Specification Elements Within the `services` block, a list of maps should be supplied, with each map defining a `ServiceSpecification`. Each `ServiceSpecification` should declare the @@ -63,7 +63,7 @@ these declared flags and config keys may be passed in at the root of the `Servic (Undeclared config is only accepted in the `brooklyn.config` map.) -## `LocationSpecification` Elements +## Location Specification Elements <!-- TODO - expand this, currently it's concise notes --> @@ -142,12 +142,17 @@ However you can combine locations using `multi`: Dependency injection other powerful references and types can be built up within the YAML using the concise DSL defined here: -* `$brooklyn:component("ID")` refers to a Brooklyn component with the given ID; you can then access the following subfields: - * `.attributeWhenReady("sensor")` will store a future which will be blocked when it is accessed, - until the given `sensor` from the component `ID` has a "truthy" (i.e. non-trivial, non-empty, non-zero) value - * `.config("key")` will insert the value set against the given key at this entity (or nearest ancestor); - can be used to supply config at the root which is used in multiple places in the plan - * `$brooklyn:sensor("sensor.name")` returns the given sensor on the current entity if found, or an untyped (Object) sensor; +* `$brooklyn:attributeWhenReady("sensor")` will store a future which will be blocked when it is accessed, + until the given `sensor` from the component `ID` has a "truthy" (i.e. non-trivial, non-empty, non-zero) value +* `$brooklyn:config("key")` will insert the value set against the given key at this entity (or nearest ancestor); + can be used to supply config at the root which is used in multiple places in the plan +* `$brooklyn:sensor("sensor.name")` returns the given sensor on the current entity if found, or an untyped (Object) sensor; + `$brooklyn:sensor("io.brooklyn.ContainingEntityClass", "sensor.name")` returns the strongly typed sensor defined in the given class +* `$brooklyn:component("ID")` refers to a Brooklyn component with the given ID; you can then access the following subfields, + using the same syntax as defined above but with a different reference entity: + * `.attributeWhenReady("sensor")` + * `.config("key")` + * `.sensor("sensor.name")` * `$brooklyn:component("scope", "ID")` is also supported, to limit scope to any of * `global`: looks for the `ID` anywhere in the plan * `child`: looks for the `ID` anywhere in the child only @@ -158,12 +163,14 @@ concise DSL defined here: * `$brooklyn:formatString("pattern e.g. %s %s", "field 1", "field 2")` returns a future which creates the formatted string with the given parameters, where parameters may be strings *or* other tasks such as `attributeWhenReady` * `$brooklyn:literal("string")` returns the given string as a literal (suppressing any `$brooklyn:` expansion) - `$brooklyn:sensor("io.brooklyn.ContainingEntityClass", "sensor.name")` returns the strongly typed sensor defined in the given class +* `$brooklyn:object(Map)` creates an object, using keys `type` to define the java type, + and either `object.fields` or `brooklyn.config` to supply bean/constructor/flags to create an instance * `$brooklyn:entitySpec(Map)` returns a new `ServiceSpecification` as defined by the given `Map`, but as an `EntitySpec` suitable for setting as the value of `ConfigKey<EntitySpec>` config items (such as `memberSpec` in `DynamicCluster`) -These can be supplied either as strings or as lists and maps in YAML. +Parameters above can be supplied either as strings or as lists and maps in YAML, +and the `$brooklyn:` syntax can be used within those parameters. ## Some Powerful YAML Entities
