Giter Site home page Giter Site logo

accordproject / concerto Goto Github PK

View Code? Open in Web Editor NEW
98.0 98.0 96.0 110.51 MB

Business schema language and runtime

Home Page: https://concerto.accordproject.org

License: Apache License 2.0

JavaScript 90.37% Nunjucks 0.06% PEG.js 3.74% TypeScript 5.84%
json models schema types typescript validate validator

concerto's People

Contributors

andrew-coleman avatar awjh-ibm avatar bestbeforetoday avatar cazfletch avatar davidkel avatar dependabot[bot] avatar dselman avatar edmoffatt avatar edprosser avatar ellishenderson avatar erin-hughes avatar fabric-composer-app avatar fenglianxu avatar github-actions[bot] avatar jakeeyturner avatar jeromesimeon avatar joepavitt avatar jonathan-casey avatar jt-nti avatar kaiusher avatar liam-grace avatar mbwhite avatar mttrbrts avatar nklincoln avatar odowdaibm avatar ragi-dayananda avatar rthatcher avatar samjsmith avatar tobias-hunter avatar winslet avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

concerto's Issues

Optimize size of Concerto parser

The JS for the CTO parser is currently very large and should be optimised to make the web packed version of Concerto much smaller. The parser currently includes many pegjs rules inherited from JS that could be removed.

[74] ./lib/introspect/parser.js 545 KiB {0} [depth 3] [built]

This is also an opportunity to take a step back and evaluate other parser generators. I am particularly interested in being able to generate a CTO parser for other languages. E.g. Canopy supports Java, JS, Ruby and Python. ANLR4 (while written in Java) can also generate JS amongst many other languages: https://github.com/antlr/antlr4

http://canopy.jcoglan.com/

References:
https://tomassetti.me/parsing-in-javascript/
https://en.wikipedia.org/wiki/Comparison_of_parser_generators

typo in readme

Context

typo in readme (optionall)

Expected Behavior

typo free readme

Actual Behavior

has a typo

Possible Fix

change the spelling

Steps to Reproduce

  1. visit the repo's readme

Existing issues

Context

skimming through the readme

Your Environment

  • Version used:
  • Environment name and version (e.g. Chrome 39, node.js 5.4):
  • Operating System and version (desktop or mobile):
  • Link to your project:

Text variant annotation for model enumerations

To support textual variants of the same enumeration element in a model, the model definition should allow annotations that enumerate text alternatives.

The annotation could also be used to capture language-specific variants of a model element.

This would clean up model enumerations so that they only need to define a single element per semantic element. Logic that operates on enumerations (for example match statements in Ergo) would then also not need to match multiple values

Where an annotation is not provided, the String value of the element would be used.

For example:

enum TemporalUnit {
  @alternativeText('day','days','jour','jours')
  o DAY
  //...
}

We could even consider something like a .language file to externalize language definitions, e.g.

enum TemporalUnit {
  @languageKey('DAY')
  o DAY
  //...
}

and in model.en.language

{
  "DAY": ["day", "days"]
}
  • Agree on annotation keyword (alternative, alternativeText, verbalization, localization, textOptions etc..)
  • Research existing ways to describe locale variants, e.g. Message Resource Property files in Java, Unicode CLDR etc.

Context

This is a feature request. Original issue was posted by @mttrbrts here: accordproject/template-archive#111

Is the linter used?

If I run lint on concerto-core:

bash-3.2$ npm run lint 

> @accordproject/[email protected] lint /Users/jeromesimeon/git/concerto/packages/concerto-core
> eslint .


/Users/jeromesimeon/git/concerto/packages/concerto-core/lib/baseexception.js
  15:1  error  'use strict' is unnecessary inside of modules  strict

/Users/jeromesimeon/git/concerto/packages/concerto-core/lib/basefileexception.js
  15:1  error  'use strict' is unnecessary inside of modules  strict

/Users/jeromesimeon/git/concerto/packages/concerto-core/lib/codegen/filewriter.js
  15:1  error  'use strict' is unnecessary inside of modules  strict

/Users/jeromesimeon/git/concerto/packages/concerto-core/lib/codegen/fromjs/apisignaturegenerator.js
  15:1  error  'use strict' is unnecessary inside of modules  strict

/Users/jeromesimeon/git/concerto/packages/concerto-core/lib/codegen/fromjs/jsongenerator.js
  15:1  error  'use strict' is unnecessary inside of modules  strict

/Users/jeromesimeon/git/concerto/packages/concerto-core/lib/codegen/fromjs/plantumlgenerator.js
   15:1   error    'use strict' is unnecessary inside of modules  strict
   42:13  warning  Unexpected console statement                   no-console
   46:13  warning  Unexpected console statement                   no-console
  105:9   warning  Unexpected console statement                   no-console
  106:9   warning  Unexpected console statement                   no-console
  107:9   warning  Unexpected console statement                   no-console
  110:9   warning  Unexpected console statement                   no-console
...

Runtime execution over missing fields when field is optional

The current JavaScript backend code generation expects JSON with a field containing null for optional fields in the CTO model.

So for a concept:

concept C{
  o Integer a optional
}

The expected serialization is currently:

{ "$class" : "C", "a" : null }

This is inconsistent with the way Concerto validates optional fields, instead assuming the default serialization is:

{ "$class" : "C" }

It would be useful to support both serialization in Ergo.

Note that it might be less confusing to Ergo user is the default Concerto serialization use the null form, since in Ergo, you always have to write:

C{ a: none }

Concerto CLI usage should use the "concerto" name instead of the generic "cli"

The concerto CLI help shows:

bash-3.2$ concerto --version
0.80.4-20191002122338
bash-3.2$ concerto --help
cli <cmd> [args]

Commands:
  cli generate  generate code from model files
  cli get       save local copies of external model dependencies

Options:
  --version      Show version number                                   [boolean]
  --verbose, -v                                                 [default: false]
  --help         Show help                                             [boolean]
bash-3.2$ 

It should say instead:

bash-3.2$ concerto --help
concerto <cmd> [args]

Commands:
  concerto generate  generate code from model files
  concerto get       save local copies of external model dependencies

Options:
  --version      Show version number                                   [boolean]
  --verbose, -v                                                 [default: false]
  --help         Show help                                             [boolean]
bash-3.2$ 

Confusing error message - Concerto CLI

Is your feature request related to a problem? Please describe.
The error message that appears when I enter incorrect commands are confusing and quite generic.

hyewon@hobbang:~/Accord_Project/cicero-template-library/src/latedeliveryandpenalty$ concerto validate 
15:13:21 - error: ENOENT: no such file or directory, open 'sample.json'

hyewon@hobbang:~/Accord_Project/cicero-template-library/src/latedeliveryandpenalty$ concerto compile
15:13:29 - error: EISDIR: illegal operation on a directory, read

hyewon@hobbang:~/Accord_Project/cicero-template-library/src/latedeliveryandpenalty$ concerto get
15:13:32 - error: EISDIR: illegal operation on a directory, read

hyewon@hobbang:~/Accord_Project/cicero-template-library/src/latedeliveryandpenalty/models$ concerto compile clause.cto --target Go
15:13:41 - error: EISDIR: illegal operation on a directory, read

Describe the solution you'd like
More informative error messages.

For example, this error message (when I used a wrong .json file) was quite helpful:

hyewon@hobbang:~/Accord_Project/cicero-template-library/src/latedeliveryandpenalty$ concerto validate --sample package.json --ctoFiles models/clause.cto
15:10:08 - error: Invalid JSON data. Does not contain a $class type identifier.

For the code snippet above, for example concerto compile clause.cto --target Go, an error message could be something like:

error: target CTO file unclear. 
Try including --ctoFiles in front of the target CTO files you want to convert

or a more generic, but more specific, error message (compared to EISDIR) would be:

error: cannot find command arguments. 
Try using `concerto compile --ctoFiles <filename> --target <targetFormat>`

Describe alternatives you've considered
N/A

Additional context
concerto version 0.82.4

java.time.Instant rather than java.util.Date in the Java target format?

Is it recommended best practice to use Java.time rather than the older (and considered poorly designed) Java.util.date, as currently used by the concerto-tools Java target.

Context

This isn't a bug, but a suggestion for improvement.

Expected Behavior

CTO concepts making use of the DateTime atomic types should generate Java classes with fields using java.time.Instant.

Actual Behavior

CTO concepts making use of the DateTime atomic types generate Java classes with fields using java.util.Date.

Possible Fix

Maybe, just this line to change:

Remove support for system models

Support for system models has complicated the codebase and makes it hard to reuse models, as they now have an implicit dependency on a system model.

On balance I think we should make a breaking change and remove the support for system models, forcing people to explicitly declare dependencies on their own models using an import with a from.

Concerto Core has the wrong package name

Describe the bug
Wrong package name.

The structure of the lerna packages in the code is:

concerto-core
concerto-tools
concerto-cli

But the package name (and the published package on npmjs) for concerto-core is still concerto. I think it would make sense to change that to avoid confusion, and align with other Accord Project packages structure/naming.

Corresponding line, I believe:

"name": "@accordproject/concerto",

Add coverall coverage report and badge

We should report test coverage for the whole monorepo, including a badge in the README.

Tasks:

  • Add test coverage to Cicero-cli
  • Add combined coverage report for all the packages and publish to coverall
  • Add badge to README

[mkdirp should be a dependency] dependencies in composer concerto

Context

mkdirp appears as a devDependency but is needed at runtime in the filewriter.

Expected Behavior

One should be able to install and use composer-concerto without adding mkdirp as a dependency themselves.

Actual Behavior

If installing composer-concerto without adding mkdirp manually, node.js complains of a missing module.

Possible Fix

Move mkdirp from devDependencies to dependencies in the package.json

Steps to Reproduce

See: accordproject/ergo#591

Existing issues

Context

Using composer-concerto as part of the Ergo project https://github.com/accordproject/ergo

Your Environment

  • Version used: 0.70.0
  • Environment name and version (e.g. Chrome 39, node.js 5.4): node8
  • Operating System and version (desktop or mobile): MacOS X
  • Link to your project:

Move `parsejs` and dependencies to the `./scripts` directory

As far as I can tell, ./lib/codegen/parsejs.js is only used as a developers dependency for generating the API documentation. It should be moved to a build-time directory such as scripts.

Context

There are a number of dependencies e.g., acorn and doctrine which are not needed at runtime, but are placed in the ./lib directory. This means any consumer of the composer-concerto package must also have those.

They also get bundled in through WebPack unnecessarily.

Expected Behavior

Same behaviour as not but without the dependencies to acorn and doctrine, etc.

Actual Behavior

Some current build-time dependencies are made necessary at runtime.

Possible Fix

  • Move the following: ./lib/codegen/parsejs.js and ./lib/codegen/javascriptparser.js to ./scripts
  • Move acorn and doctrine from dependencies to devDependencies.

Steps to Reproduce

Existing issues

This led to issue #43

Context

Forced to add unnecessarily acorn and doctrine upstream in a consumer of Composer Concerto (Accord Project's Cicero and related packages).

Your Environment

  • Version used: 0.71.6
  • Environment name and version (e.g. Chrome 39, node.js 5.4): node.js 8
  • Operating System and version (desktop or mobile): MacOS
  • Link to your project:

Serialization of Infinity is null

Describe the bug
When an expression sets a value in the state to Infinity, this gets serialized (through JSON.stringify?) to null. This has the effect of invalidating the state instance and rendering the contract unable to accept new requests.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#Description

The numbers Infinity and NaN, as well as the value null, are all considered null.

To Reproduce
Steps to reproduce the behavior:
infinity.ergo

namespace matt.inf

import org.accordproject.cicero.contract.*
import org.accordproject.cicero.runtime.*

contract Inf over InfContract {
    clause infTest(request: Request): Response {
        set state InfContractState {
            stateId: "inf0",
            value: 1.0 / 0.0
        };
        return Response{}
    }
}

model.cto

namespace matt.inf

import org.accordproject.cicero.contract.* from https://models.accordproject.org/cicero/contract.cto
import org.accordproject.cicero.runtime.* from https://models.accordproject.org/cicero/runtime.cto

asset InfContractState extends AccordContractState {
    o Double value
}

asset InfContract extends AccordContract {}

state.json

{
    "$class": "matt.inf.InfContractState",
    "stateId": "state1",
    "value": 0.0
}

contract.json

{
    "$class": "matt.inf.InfContract",
    "contractId": "contract1"
}

request.json

{
    "$class": "org.accordproject.cicero.runtime.Request"
}

When you run ...

mattmbp:minimal matt$ ergorun execute --contract contract.json --request request.json --state state.json  model.cto infinity.ergo
09:05:31 - info:
{
  "clause": "mattXinfXInf",
  "request": {
    "$class": "org.accordproject.cicero.runtime.Request",
    "transactionId": "54280e38-bfda-43f1-98d1-9048a64d7aeb",
    "timestamp": "2019-08-16T08:05:31.493Z"
  },
  "response": {
    "$class": "org.accordproject.cicero.runtime.Response",
    "transactionId": "994be5fe-39b9-451e-9aa1-5e6a0fc90e3e",
    "timestamp": "2019-08-16T08:05:31.504Z"
  },
  "state": {
    "$class": "matt.inf.InfContractState",
    "value": null,
    "stateId": "inf0"
  },
  "emit": []
}

Notice the value of value in the state response.

If you then update the value of state.json with the new state, it will fail to pass validation.

mattmbp:minimal matt$ ergorun execute --contract contract.json --request request.json --state state.json  model.cto infinity.ergo
09:05:41 - error: Instance matt.inf.InfContractState#state1 missing required field value

Expected behavior
The engine should throw a runtime error, perhaps similar to an enforce response, to alert the client to the overflow and protect corruption of the state.

Typo in DEVELOPERS.md

Describe the bug

  1. In DEVELOPERS.md (here), need to replace Cicero with Concerto.

  2. In section building concerto (here), URL of the main repository to be added as upstream has a typo in it. acccordproject should be accordproject

To Reproduce
Steps to reproduce the behavior:

  1. Go to DEVELOPERS.md
  2. Check 'Add the main repository as an upstream remote to your repository'
  3. Notice the typo in URL

Expected behavior
Instead of acccordproject, it should be accordproject, and Cicero should be replaced with Concerto

Add file location information to ValidationExceptions and TypeNotFoundExceptions when possible

Is your feature request related to a problem? Please describe.
Most errors include location information, but validation and type not found errors do not.

Describe the solution you'd like
When validating a JSON instance against a model fails, provide location information for where the error occurred in the JSON instance.

When loading a model which has an unknown type, provide location information for where that type is used in the model.

Describe alternatives you've considered
I haven't.

Additional context
Here is an example of an exception with location information (it inherits from BaseFileException):
https://github.com/accordproject/concerto/blob/master/packages/concerto-core/lib/introspect/parseexception.js

Currently when running the CLI in those cases:

bash-3.2$ concerto generate --ctoFiles test/models/typenotfound.cto
Undeclared type BUBBLE in property org.accordproject.money.CryptoMonetaryAmount.doubleValue File 'test/models/typenotfound.cto':  IllegalModelException: Undeclared type BUBBLE in property org.accordproject.money.CryptoMonetaryAmount.doubleValue File 'test/models/typenotfound.cto': 
bash-3.2$ 
bash-3.2$ concerto validate --ctoFiles test/models/money.cto --sample test/data/sample2.json 
Instance undefined invalid enum value true for field CurrencyCode ValidationException: Instance undefined invalid enum value true for field CurrencyCode

Compared to the case where a file location is available:

bash-3.2$ concerto generate --ctoFiles test/models/parseerror.cto 
Expected "-->", "@", "default", "o", "optional", "}", comment, end of line, or whitespace but "e" found. File test/models/parseerror.cto line 14 column 1 ParseException: Expected "-->", "@", "default", "o", "optional", "}", comment, end of line, or whitespace but "e" found. File test/models/parseerror.cto line 14 column 1

Implicit super types specification

We allow the ModelManager to specify implicit super types for class declarations (currently via a map). The map based approach has a couple of issues:

  1. It doesn't work well when multiple system namespaces have been added as the return value is a type name without a namespace
  2. It is not clear whether we should only allow implicit super types when there is no explicit super type
  3. Should we allow implicit super types for types that are not defined in a system model file?

This is also related to the ClassDeclaration.isSystemCoreType method.

Consolidate Concerto code into a single repository

Is your feature request related to a problem? Please describe.
The code is currently split across two projects: concerto and concerto-tools. It might be useful for maintenance (versioning, testing) if those are consolidated under a single project.

Describe the solution you'd like
A mono repo using lerna which would include:

  • concerto-core the core model manager/validator
  • concerto-tools auxiliary code for other schema languages generation
  • concerto-cli for a command line (See #67)

Possibly, a concerto-test project could also be considered.

Additional context
This would also align with the structure for other Accord Project repositories (e.g., Cicero and Ergo).

cannot find module error

When I use composer-concerto into another package and then I use this new package into an application it throws this error:
Error: Cannot find module 'doctrine'

Context

doctrine and acorn are required by the application but have been moved in devDependencies

Expected Behavior

no errors

Actual Behavior

this error:
Error: Cannot find module 'doctrine'

Possible Fix

move doctrine and acorn to dependencies

Steps to Reproduce

  1. use composer-concerto in a module
  2. import the module into an application
  3. run the application

Context

import composer-concerto in another package

Your Environment

  • Version used: 0.71.3
  • Environment name and version (e.g. Chrome 39, node.js 5.4): node.js v11.10.1
  • Operating System and version (desktop or mobile): Fedora Linux
  • Link to your project:

isSystemType specification

Again, this implies that there is a single system namespace.

/**
     * Returns true is this type is in the system namespace
     *
     * @return {boolean} true if the class may be pointed to by a relationship
     */
    isSystemType() {
        return this.modelFile.isSystemModelFile();
    }

Link broken in Contributing.md

There is a link to Code of Conduct link in contributing.md file that need to be fixed . It is a issue to be solved as soon as possible so that people are aware about accord code of conduct.

Remove FileWriter

It would be great to move FileWriter into its own or another module (concerto-tools?). It depends on mkdirp which drags in minimist.

Automated API Verification should prompt user to change the Typescript definition

Is your feature request related to a problem? Please describe.
Now that Concerto has a TypeScript definition, #80 we need to make sure that it is kept up to date. Doing this automatically will be difficult because JS doesn't have all of the info required to generate TS definitions. However, we can alert developers who make API changes using the existing versionchecker.js script.

Describe the solution you'd like
Extend the versionchecker.js script to remind users who make API changes to also update the packages/concerto-core/types/index.d.ts file.

Support variant serialization/deserialization for the latest Ergo runtime

Is your feature request related to a problem? Please describe.
Ergo 0.20.* relies on a few changes to the Concerto serialisation that have to be consistent with the Ergo JavaScript run time. The changes include:

  • Alternative representation for enums consistent with the new typed enums in Ergo
  • Alternative representation for Integer and Long values to ensure proper printing in toString and in the templates support
  • Additional option for serialisation of relationships

This should be controlled by a proper option on the serialiser and ensure backward compatibility when that option is turned off (which should be the default).

Describe the solution you'd like
Fold changes for that serialization from the Ergo 0.20 branch into Concerto, which avoid much code duplication and provides for better and more systematic testing.

Additional context
This is part of a core refactoring for the 0.20 release. This change will also facilitate review and discussion for improvements in future releases.

serialization/deserialization does not preserve timezones in dates

Context

Using Concerto for data models with DateTime values in specific timezones

Expected Behavior

Deserialization/serialization should preserve the original timezone.

Actual Behavior

Deserialization/serialization shifts all dates to Z timezone.

Possible Fix

Unclear what changes are needed.

Steps to Reproduce

Some sample code, and a trace:
Model:

transaction PayOut  {
  o Double totalAmount
  o DateTime dueBy
}

JavaScript code:

        const response = {
            "$class": "org.accordproject.ippayment.PayOut",
            "totalAmount": 77.4,
            "dueBy": Moment.parseZone("2018-04-12T04:00:00-05:00")
        };
        const validatedResponse = template.getSerializer().fromJSON(response);
        const serializedResponse = template.getSerializer().toJSON(validatedResponse);
        console.log('JSON:       '+JSON.stringify(response));
        console.log('VALIDATED:  '+JSON.stringify(validatedResponse));
        console.log('SERIALIZED: '+JSON.stringify(serializedResponse));

Trace:

JSON:       {"$class":"org.accordproject.ippayment.PayOut","totalAmount":77.4,"dueBy":"2018-04-12T04:00:00-05:00"}
VALIDATED:  {"$class":"org.accordproject.ippayment.PayOut","totalAmount":77.4,"dueBy":"2018-04-12T09:00:00.000Z","transactionId":"afc5fb0c-a776-44f7-9327-a47339aecdda","timestamp":"2019-03-06T13:12:37.640Z"}
SERIALIZED: {"$class":"org.accordproject.ippayment.PayOut","totalAmount":77.4,"dueBy":"2018-04-12T09:00:00.000Z","transactionId":"afc5fb0c-a776-44f7-9327-a47339aecdda","timestamp":"2019-03-06T13:12:37.640Z"}

Context

I'm trying to use Concerto inside the accord project Cicero. Maintaining timezone information in date is important for applications.

Your Environment

  • Version used: 0.60.0
  • Environment name and version (e.g. Chrome 39, node.js 5.4): node8
  • Operating System and version (desktop or mobile): MacOS
  • Link to your project: https://github.com/accordproject/cicero

[Feature] Provide a toString() method for enumerated values in Java

It would be convenient to provide a way to easily get the string name for enumerated values. For instance to get the name of a currencyCode as a Java String.

Context

It's not a bug, but feature request.

Expected Behavior

Calling myEnum.toString() should return the name of the enum as a Java String.

Actual Behavior

The application has to create string representations (e.g., through myEnum.name()) by hand.

Possible Fix

Add a toString() method for enums, maybe using .name() for enums.

Steps to Reproduce

N/A

Existing issues

None found.

Context

Working on an application where CTO models are generated to Java with additional fixes for the Corda network. Monetary amounts CTO representations which include an enum for currency codes are converted to Java Currency classes.

Your Environment

  • Version used: 0.70.2
  • Environment name and version (e.g. Chrome 39, node.js 5.4): node 8
  • Operating System and version (desktop or mobile): MacOS
  • Link to your project: https://github.com/accordproject/cicero

Avoid `instanceof` which leads to runtime errors with deep npm dependencies

The use of instanceof to check whether an object is of a class leads to unreliable check when importing Composer Concerto in projects with deep npm dependencies.

Context

Composer Concerto uses instanceof checks e.g., here https://github.com/hyperledger/composer-concerto/blob/37189e52c4f52d13cbd862b38d36a64022976398/lib/serializer/resourcevalidator.js#L72 or here https://github.com/hyperledger/composer-concerto/blob/37189e52c4f52d13cbd862b38d36a64022976398/lib/serializer/jsonpopulator.js#L96

Those can be unreliable since it checks whether this is the same object from the exact same package installed in a node.js project.

The reason it is unreliable is that it is difficult to enforce that the corresponding version of composer-concerto is installed exactly once in the ./node_modules directory through npm install.

This can lead to runtime errors when doing validation/serialization in some projects with deep npm dependencies.

Expected Behavior

A project should be able to import Composer Concerto 0.7.1 and PROJECT 0.X.X depending on e.g., Composer Concerto 0.7.0 without leading to runtime errors.

Actual Behavior

Currently a project has to ensure every dependency which import Composer Concerto have the exact same version, and that npm install leads to only one copy of that same version, which is difficult to guarantee (due to the way npm install works).

Possible Fix

Several fixes are suggested in: https://stackoverflow.com/questions/41587865/using-instanceof-on-objects-created-with-constructors-from-deep-npm-dependenci

The recommended fix is to use an explicit method to check whether an object has the expected class. So instead of writing thing instanceof RelationshipDeclaration one would write isRelationshipDeclaration(thing) where:

RelationshipDeclaration.prototype._isRelationshipDeclaration = true;
var isRelationshipDeclaration = function isRelationshipDeclaration(obj) {
  return obj instanceof RelationshipDeclaration || Boolean(obj._isRelationshipDeclaration);
};

module.exports = {
  RelationshipDeclaration,
  isRelationshipDeclaration
};

Steps to Reproduce

Existing issues

Context

Importing Composer Concerto in various parts of the Accord Project (Ergo, Cicero, Cicero template library, template studio, etc.).

Your Environment

  • Version used: 0.70.*
  • Environment name and version (e.g. Chrome 39, node.js 5.4): node.js 8
  • Operating System and version (desktop or mobile): MacOS
  • Link to your project:

Request CTO validation is not working

Describe the bug
It is possible to send an invalid request (with respect to the CTO model) and have the Ergo execute.

To Reproduce

  1. Download the attached template
  2. Using the request and state within the archive
  3. cicero execute --request monthlysales-invalid.json --state state.json
  4. Note that execution succeeds, when it should fail

Expected behavior
The execution should fail because sales[0].price.doubleValue is a string.

Version

Cicero 0.13.5

Ability to save a ModelManager to a set of CTO files

Is your feature request related to a problem? Please describe.
There is currently no mechanism to modify a ModelFile in memory and then persist those changes back out to disk.

Describe the solution you'd like
Add a visitor to concerto-tools that visits a ModelManager and generates CTO files that can be round tripped.

Additional context
This feature would allow someone to build a graphical CTO file editor, with persistence back out to CTO files.

Release Notes (v0.20 Project)

Tasks

  • This will track and construct the overall release notes for this repo in relation to the v0.20 project
    • Will cover everything from the inception of this repo

Related Issues:

  • N/A

Support for offline download of external models

Is your feature request related to a problem? Please describe.
The ability to resolve and download external model to a local directory.

Describe the solution you'd like
A command line tool which lets people resolve external model references (with from) and generate files in a given directory.

Additional context
In addition to being a useful tool for users, some of the Accord Project stack depends on external models at build time (markdown-transform requires CommonMark and CiceroMark ASTs, and ergo-compiler requires base models for the contract and runtime).

Codegen should be a separate npm module

The Codegen functionality drags in quite a few dependencies. We should move that into a separate module composer-concerto-tools ?

Add the cto command line utility to it as well.

Better Error reporting for Concerto CLI

Is your feature request related to a problem? Please describe.
Errors reported by the Concerto CLI are not terribly well formatted, and sometimes include duplicate text.

Describe the solution you'd like
Nicer looking errors, maybe using the logger we use in other parts of the Accord Project code base. Properly print the useful part of the error, without repetition.

Additional context
Some examples:

bash-3.2$ concerto validate --ctoFiles test/models/money.cto --sample test/data/sample2.json 
Instance undefined invalid enum value true for field CurrencyCode ValidationException: Instance undefined invalid enum value true for field CurrencyCode
bash-3.2$ concerto validate --ctoFiles test/models/moneyErr.cto --sample test/data/sample2.json 
Expected "-->", "@", "default", "o", "optional", "}", comment, end of line, or whitespace but "e" found. File test/models/moneyErr.cto line 14 column 1 ParseException: Expected "-->", "@", "default", "o", "optional", "}", comment, end of line, or whitespace but "e" found. File test/models/moneyErr.cto line 14 column 1
bash-3.2$ concerto generate --ctoFiles test/models/moneyErr.cto
Expected "-->", "@", "default", "o", "optional", "}", comment, end of line, or whitespace but "e" found. File test/models/moneyErr.cto line 14 column 1 ParseException: Expected "-->", "@", "default", "o", "optional", "}", comment, end of line, or whitespace but "e" found. File test/models/moneyErr.cto line 14 column 1

Command line tool for Concerto

Is your feature request related to a problem? Please describe.
It would be useful to offer a command line interface (CLI) for concerto. This could be used to test whether a JSON document validate against a model, for generating other schema languages (XML Schema, JSONSchema, etc) from a model, or to resolve external models (See #66).

Describe the solution you'd like
The CLI could be called concerto followed by a command and options:

  • concerto validate for validation
  • concerto generate for generating other scheme languages
  • concerto get for resolving models

getSystemType specification

The method AssetDeclaration.getSystemType (and in all other types) is under specified and implies that there is a single system namespace.

    /**
     * Returns the base system type for Assets from the system namespace
     *
     * @return {string} the short name of the base system type
     */
    getSystemType() {
        return this.modelFile.getModelManager().getSystemModelTable().get('Asset');
    }

Concerto CLI fails on some Accord Project models

Describe the bug
The CLI (e.g., concerto generate) fails on well formed and valid models from the Accord Project.
A clear and concise description of what the bug is.

To Reproduce

E.g., using examples from cicero-models:

bash-3.2$ cd ~/git/cicero-models/src/
bash-3.2$ concerto --version
0.80.4-20191003155034
bash-3.2$ concerto generate --ctoFiles signature/signature.cto 
Class ContractSigned is not declared as abstract. It must define an identifying field. File 'signature/signature.cto': line 9 column 1, to line 11 column 2.  IllegalModelException: Class ContractSigned is not declared as abstract. It must define an identifying field. File 'signature/signature.cto': line 9 column 1, to line 11 column 2. 
bash-3.2$ concerto generate --ctoFiles cicero/contract.cto 
Generated JSONSchema code.
bash-3.2$ concerto generate --ctoFiles cicero/runtime.cto 
Class Request is not declared as abstract. It must define an identifying field. File 'cicero/runtime.cto': line 13 column 1, to line 13 column 23.  IllegalModelException: Class Request is not declared as abstract. It must define an identifying field. File 'cicero/runtime.cto': line 13 column 1, to line 13 column 23. 
bash-3.2$ 

Additional context
This is most likely due to distinct systems models. See also #62

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.