Playground: Code for some entries isn't highlighted

[postatum]

Christian Vogel
seems something is wrong with marking specific things inside the editor
1. Load Uber API (OAS)
2. Select Modular Units
3. Click on "Product"
4. Check is correctly marked in the RAML view
5. It is not marked inside the OAS view
It also happens with the World Music Example
I don't get any marking for the "Entry" but for "User" on the RAML view.
On the OAS view, I get marking for "Entry" also.

[postatum]

This is most likely related to #43

[antoniogarrote]

Correct. They are missing lexical info, we cannot highlight it.
Potential quick workaround: entries with missing info are always going to be single lines in the same locations: type references in RAML types: section, traits in RAML traits: section and their equivalent in OpenAPI (#/definitions). Once the text for the editor has been generated it should be possible to split it in lines and find the lines for the tokens with missing lexical info just using a regular expression. Only a temporary fix.

[antoniogarrote]

This proposed fix is for the front-end. Not for the library.

[antoniogarrote]

I have finished the code for RAML files.
Unfortunately I don´t have a connection to the internet available from my computer. I can only use a public machine. To make things worst, Google Authenticator doesn´t work in this country so I cannot even email a patch.

I have created a Gist with the patch and a new test file. @postatum you can try applying the patch and checking that the test pass and the front end works correctly.

This is the URL to the gist: https://gist.github.com/antoniogarrote/c7ff134b2d77a3143b0234372048ec39

If I can get connected at some point, I will try to do it on my own, but not sure if that´s going to be the case.

[postatum]

Hi @antoniogarrote. Thanks a lot for your help!

I've applied your patch. Tests pass, but frontend seems to be working incorrectly.
Here's how RAML looks when loading Open API project (Uber API):

#%RAML 1.0
title:
  amf-lexical-token: Uber API
description:
  amf-lexical-token: Move your app forward with the Uber API
version:
  amf-lexical-token: 1.0.0
baseUri:
  amf-lexical-token: api.uber.com/v1

And when I try to load RAML project (World Music API), I get an error

"TypeError: path.indexOf is not a function
    at resolvePath (<anonymous>:4114:14)
    at collectLibraries (<anonymous>:4215:36)
    at <anonymous>:4262:13
    at updateFragments (<anonymous>:4142:9)
    at <anonymous>:4167:17
    at <anonymous>:4104:13"

Here's how I applied your changes:

1. Created common_test.cljc in api_modeling_framework/parser/domain/common_test.cljc
2. Saved your diff to a file
3. In your code/diff I've replaced modelling with modeling because we've renamed the project.
4. Applied diff with git apply
5. Compile-copy with lein web && mv output/web/amf.js ~/projects/mulesoft/amf-playground/public/js/

[postatum]

@antoniogarrote
Update:
Looks like the bug with loading RAML project is fixed by recreating JS bundle with browserify -s yaml yaml.js > js-support-bundle.js, because there's a mistake in bundle file from diff.

When using fixed bundle, project is loaded but some errors are logged in Chrome console:

ERROR COMPACTING
VM4239:86452 JsonLdError {stack: "Error↵    at JsonLdError (<anonymous>:22252:19)↵  …8568:14)↵    at drainQueue (<anonymous>:48538:42)", name: "jsonld.CompactError", message: "Could not expand input before compaction.", details: Object}
VM4239:87157 Error getting ApiModel
VM4239:87158 JsonLdError {stack: "Error↵    at JsonLdError (<anonymous>:22252:19)↵  …8568:14)↵    at drainQueue (<anonymous>:48538:42)", name: "jsonld.CompactError", message: "Could not expand input before compaction.", details: Object}

After the fix(new bundle), in World Music API, in tab Modular Units and RAML editor:

• AnotherEntry isn't selected
• Entry is selected with types: line
• User is selected properly

[antoniogarrote]

Hi @postatum thanks for trying the fix.
The JSONLD error migh be because something is generating a nil @id.
the problem with AnotherEntry and Entry is weird, because I added assertions in the integration test to check that they were generating lexical info. Unfortunately I cannot run the fronotend here, so I'm afraid we will not be able to finish this in time. If I come across a wifi with enough bandwidth to download dependencies and build the app, I will try to fix the problem.
You can also check if no info is generated for those declarations or the problem is that the info is wrong.

[postatum]

@antoniogarrote Here's a JSON of (what I think is) lexical info https://gist.github.com/postatum/93ca867bc84c050eafb040f8cd572a09

Unfortunately I can't interpret it properly. It's an info of World Music API.
I've got it by logging res inside core.lexical-info-for-unit.