Hi Thomas-
> I get that it could be handy to use our YAML as JSON. Do you have any
examples of this
> kind of use within the Brooklyn ecosystem?
There are quite a few places this is done including when you deploy, the
first-pass parse at the Brooklyn server. It's a second pass interprets
@Alex, @Svet, @Andrew: I get that it could be handy to use our YAML as
JSON. Do you have any examples of this kind of use within the Brooklyn
ecosystem?
If not, this is not a compelling argument to me because again, our YAML is
currently not valid: we shouldn't use any `$brooklyn:(.+)` as key if
Agree with that. Something I wrote a couple of hours ago while offline, so
didn't see Alex's email:
Something to have in mind when discussing this - YAML is a superset of JSON as
all of you are well aware. Today we can express the Brooklyn CAMP spec
completely in JSON and it will just work.
The ability to switch between json and yaml (so we only use the
json-isomorphic subset) is nice for working with models eg is js in the
browser, and feels less intimidating to new people. I'd like anywhere we
use !! to be optional. (if it were a more widely used part of yaml I might
think
Hi.
The 'formatString' example you quote would normally be written like this,
though:
brooklyn.config:
brooklyn.example.db.url:
$brooklyn:formatString:
- "jdbc:%s%s?user=%s\\=%s"
- $brooklyn:component("db").attributeWhenReady("datastore.url")
- "visitors"
Hi Thomas,
Don't have an opinion on the custom types yet. I'm not sure I understand the
reasoning behind the proposal. Are you saying that if we use xxx:
"$brooklyn:formatString(\"jdbc:...\",
component(\"db\").attributeWhenReady(\"url\"))" it won't get converted to a
DslComponent, but will be
Hi All
The YAML spec[1] has a very nice and standard way of defining custom types
by prefixing any value or object by a `!!`. This seems like a
perfect feature for the Brooklyn DSL instead of the `$brooklyn:`.
Let's me explain why.
Right now, a Brooklyn DSL command needs to be written as a
