incubator-brooklyn icon indicating copy to clipboard operation
incubator-brooklyn copied to clipboard

[BROOKLYN-177] wip: drag and drop support for yaml editor

Open azbarcea opened this issue 9 years ago • 14 comments

azbarcea avatar Oct 01 '15 22:10 azbarcea

  • drag brooklyn-drag-01
  • drop brooklyn-drag-02
  • the code editor view is now persistent brooklyn-drag-03

The following known issues:

  • the drop event will paste the JSON format and not the YAML. The current text is:

is:

services: [{ type: org.apache.brooklyn.entity.brooklynnode.BrooklynEntityMirror }]

should be:

- type: org.apache.brooklyn.entity.brooklynnode.BrooklynEntityMirror

or even:

services:
- type: org.apache.brooklyn.entity.brooklynnode.BrooklynEntityMirror

To make the drop event context dependent (exists or not the services:), then, a javascript yaml (blueprint) parser should be created (like [1]). It should understand CAMP syntax.

References: [1] - http://www.json2yaml.com/

azbarcea avatar Oct 01 '15 22:10 azbarcea

btw Brooklyn already has a YAML parser included - https://github.com/nodeca/js-yaml, see https://github.com/apache/incubator-brooklyn/blob/23b8fa02ff6551d38c0e6baa7668559c16d24fb8/usage/jsgui/src/main/webapp/assets/js/config.js#L49

neykov avatar Oct 02 '15 05:10 neykov

What I meant, is a Brooklyn Blueprint parser, based on js-yaml. The context belongs to CAMP semantics.

What is your thought?

azbarcea avatar Oct 02 '15 05:10 azbarcea

It's in the context of your reference to http://www.json2yaml.com/, js-yaml can do the conversion from json to yaml.

neykov avatar Oct 02 '15 05:10 neykov

@neykov what @azbarcea means is we want to take the YAML syntactical parsing (via the existing Brooklyn capabilities) and extend it with the semantic meaning of the CAMP (and eventially TOSCA or Docker Compose etc.) format.

grkvlt avatar Oct 02 '15 09:10 grkvlt

@morganbrooke can you take a look at this, please?

grkvlt avatar Oct 02 '15 09:10 grkvlt

some more example how it should happen when you do drop ...

# Please add your blueprint here
services: 
- type: org.apache.brooklyn.entity.database.mariadb.MariaDbNode
#  broklyn.config:
#  - activemq.brokerName: localhost
#    activemq.install.mirror.url: http://www.mirrorservice.org/sites/ftp.apache.org/activemq
#    activemq.jetty.port: 8161
#    activemq.templateConfigurationUrl: config/activemq.xml

or even:

# Please add your blueprint here
services: 
- type: org.apache.brooklyn.entity.database.mariadb.MariaDbNode
  broklyn.config:
  - activemq.brokerName: localhost
    activemq.install.mirror.url: http://www.mirrorservice.org/sites/ftp.apache.org/activemq
    activemq.jetty.port: 8161
    activemq.templateConfigurationUrl: config/activemq.xml

The rest API returns the weird text in the planYaml field, which is not JSON, neither yaml ... Also the above text that is inserted, we should either get it from the REST API, or I could guess how to generate it.

Any of your thoughts?

azbarcea avatar Oct 02 '15 09:10 azbarcea

So if I'm understanding this correctly, I think you just need to use JSON.parse method and then stringify the YAML in the JavaScript.

morganbrooke avatar Oct 02 '15 19:10 morganbrooke

npm install json2yaml is a package manager that allows this fairly easily it looks like: http://jsontoyaml.com So maybe look into that to resolve the issue?

morganbrooke avatar Oct 02 '15 19:10 morganbrooke

Please take a look at the String you want to parse, stringify. It needs to be a valid JSON first.

Either we modify the REST or we fix it in javascript. Any ideas?

azbarcea avatar Oct 02 '15 19:10 azbarcea

I see what you're saying, let me check out a few options.

morganbrooke avatar Oct 02 '15 19:10 morganbrooke

  • The text which comes from the REST API is valid YAML, not JSON (JSON is a subset of YAML). You can do
var bp = jsyaml.load("services: [{ type: org.apache.brooklyn.entity.brooklynnode.BrooklynEntityMirror }]");
jsyaml.dump(bp);

which will spit out:

services:
- type: org.apache.brooklyn.entity.brooklynnode.BrooklynEntityMirror

Both of them are YAML, the latter one being idiomatic. But the yamlPlan is not useful in this case because:

  • The yamlPlan of catalog items is the plan used to create the item, not example usage. Try dropping 1-server-template:0.9.0-SNAPSHOT from the default catalog for example to see what I mean. What should be dropped instead is how the item is to be used, which is just the symbolicName:version pair. Having the config keys as part of the pasted data is a good idea, but this is not available from the REST API. It can still be obtained though, for example the catalog docs extract the information offline, using the CLI item-lister command.

neykov avatar Oct 05 '15 06:10 neykov

Wow, great work @neykov! Thanks!

morganbrooke avatar Oct 05 '15 16:10 morganbrooke

@azbarcea any update on this?

ahgittin avatar Oct 28 '15 13:10 ahgittin