[4/8] incubator-brooklyn git commit: tidy yaml ref docs

[he...@apache.org]

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 <al...@cloudsoftcorp.com>
Authored: Fri Apr 10 12:31:16 2015 +0100
Committer: Alex Heneveld <al...@cloudsoftcorp.com>
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