brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svetoslav Neykov <>
Subject Re: [PROPOSAL] Brooklyn DSL in YAML using custom YAML types
Date Thu, 14 Jul 2016 05:59:23 GMT
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 used as the plain string instead? Brooklyn
will convert the string to an object after the parsing stage, so it doesn't really care what
format was used for serializing it, that's why I want to confirm if that's what's happening.


> On 13.07.2016 г., at 15:35, Thomas Bouron <> wrote:
> 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 `!!<type_name>`. This seems like a
> perfect feature for the Brooklyn DSL instead of the `$brooklyn:<command>`.
> Let's me explain why.
> Right now, a Brooklyn DSL command needs to be written as a string such as:
> $brooklyn:formatString("jdbc:%s%s?user=%s\\&password=%s",
> component("db").attributeWhenReady("datastore.url"),
> "visitors", "brooklyn", "br00k11n")
> However, any good YAML library (such as js-yaml[2]) to parse and dump YAML
> <--> JSON would wrap this string in quotes because it contains quotes or
> reserved characters. That is the expected behaviour based on the
> specification[3]. But this is an issue for the Brooklyn parser as the value
> will be treated as a `String` and not as a `DslCommand` object.
> So my proposal is as follow: support the Brooklyn DSL as a standard custom
> YAML type. We obviously need to avoid any quote or reserved characters.
> That is relatively simple for commands that takes only one parameter, for
> instance:
>   - $brooklyn:component('my-id') could become
>      - !brooklyn:component my-id
>   - $brooklyn:entitySpec would become
>      - !brooklyn:spec
> For the more complex ones, I created a gist[4] that illustrates how this
> could work. It is more verbose than the current version but we get a rid of
> the hacky `$brooklyn` and comply fully to the YAML specification.
> Best.
> [1]
> [2]
> [3]
> [4]
> -- 
> Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
> Github:
> Twitter:

View raw message