Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Command to run generator from textX view #30

Open
danixeee opened this issue Jan 9, 2020 · 4 comments
Open

Command to run generator from textX view #30

danixeee opened this issue Jan 9, 2020 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@danixeee
Copy link
Member

danixeee commented Jan 9, 2020

image

The idea is to have a context menu (when user right-clicks on a generator item) with following options:

  • New configuration
  • Uninstall generator

EDIT: Didn't find way to create context menu, I will add inline icons instead.

where New configuration option will open a new json file like:

{
  "models": [
    "./path/to/model"
  ],
  "grammar": "path/to/grammar",
  "ignoreCase": false,
  "overwrite": false,
  "outputPath": ""
}

After saving configuration file, it should be listed under appropriate generator.

Each configuration will have three actions:

  • remove
  • edit (json file)
  • run

Extra: Configurations could be displayed using a web-view and html inside VS Code (similar like settings in VS Code itself).

@danixeee danixeee added the enhancement New feature or request label Jan 9, 2020
@danixeee danixeee self-assigned this Feb 19, 2020
@danixeee
Copy link
Member Author

image

A progress so far.

By default, configurations are saved under textX/generator-configurations but I will make that configurable (other fs location, database, ...).

@igordejanovic @goto40 Some thoughts/ideas?

@igordejanovic
Copy link
Member

@danixeee Here are some thoughts:

  • I think that config file should have language and target as mandatory
    config options. Those two will decide where in the list of generators should
    this config file be found.
  • grammar should be given if language is any (like for example dot
    generator from any model).
  • ignoreCase should only be valid if grammar is given.

I'm rethinking the set of params to textX generators. Maybe it would be better
if we have pass in file names instead of metamodel/model?

@danixeee
Copy link
Member Author

@igordejanovic Thanks for feedback.

I think that config file should have language and target as mandatory
config options. Those two will decide where in the list of generators should
this config file be found.

From issue description:

The idea is to have a context menu (when user right-clicks on a generator item) with following options:

  • New configuration
  • Uninstall generator

When user clicks on generator item, I will have language and target information. I guess I will programatically add it to the configuration file, since it will be required for running a generator.

I'm rethinking the set of params to textX generators. Maybe it would be better
if we have pass in file names instead of metamodel/model?

Do you mean instead of --language and --grammar? From a file name extension we could recognise multiple matching languages, so probably --language should be kept. Or we could try to parse a model until we find a conforming one.

@igordejanovic
Copy link
Member

igordejanovic commented Mar 27, 2020

When user clicks on generator item, I will have language and target information. I guess I will programatically add it to the configuration file, since it will be required for running a generator.

Sounds good. So it will end up in the config file. If those values are changed then the generator will be "moved" visually under appropriate node in the generator list.

Do you mean instead of --language and --grammar? From a file name extension we could recognise multiple matching languages, so probably --language should be kept. Or we could try to parse a model until we find a conforming one.

I'm thinking about current parameters of the generators call in textX. Probably that change won't affect the CLI so if you are calling generator from CLI it should work without change. Still not sure whether we should change that though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants