jhipster / jdl-studio

JDL Studio is an online JHipster Domain Language visual editor
https://start.jhipster.tech/jdl-studio/
Apache License 2.0
405 stars 114 forks source link

directives break jhipster-uml generator #3

Closed imod closed 8 years ago

imod commented 8 years ago

when I export/downlaod a *.jh file I first have to remove the directives, because the jhipster-uml does not work with directives in the file.

deepu105 commented 8 years ago

yes its a known issue, something needs to be done for this.

@MathieuAA can we do this here as it would be the simplest solution for this

would need lodash for _

function readJDLFile(file) {
  return removeDirectives(fs.readFileSync('./' + file).toString());
}

function removeDirectives(source){
    function onlyCompilables(line){
        return line[0] !== '#' ? line : ''
    }
    var lines = source.split('\n').map(function (s, i){
        return {text: s.trim(), index: i }
    })
    return _.map(_.pluck(lines, 'text'), onlyCompilables).join('\n').trim()
}
MathieuAA commented 8 years ago

Can't we do that in the JDL studio? I don't want to add something that isn't directly related to the JDL or one of its dependencies... Another solution would be to add '#' as comments... but that would make '#' equivalent to '//'; and it's a redundancy.

deepu105 commented 8 years ago

If I strip this in generated file Then when users import it back they would loose the directives as well.

Its not exactly unrelated since JDL studio is exclusively for JDL and you already do these kind of things for other UML editors so JDL studio is just an editor for JDL IMO

MathieuAA commented 8 years ago

Yeah but we depend on the editors... And the studio depends on the JDL, not the other way around... And the JDL would indirectly depend on whatever introduced the '#' char... That being said, I may have an idea.

What if from the JDL Studio we have something like:

# Something like this
...

The user clicks on the "Export" button, which would then give him:

//# Something like this
...

We can then parse it without errors and it would be ignored in the JSONs. I didn't check if there was an import function in the studio, but then this

//# Something like this
...

would then be parsed and returned as

# Something like this
...

Even copy/pasting could be an event trigger.

deepu105 commented 8 years ago

Studio doesnt depend on JDL it just uses the same peg parser thats it. And I dont see how it is different from ignoring stuff in an xmi files which we do not need. Say for example if genmymodel adds some stuff in the xmi we would have to parse it out anyways this is similar to that. Just look at JDL studio like genmymodel for JDL On 10 Mar 2016 18:29, "Mathieu ABOU-AICHI" notifications@github.com wrote:

Yeah but we depend on the editors... And the studio depends on the JDL, not the other way around... That being said, I may have an idea.

What if from the JDL Studio we have something like:

Something like this

...

The user clicks on the "Export" button, which would then give him:

//# Something like this ...

We can then parse it without errors and it would be ignored in the JSONs. I didn't check if there was an import function in the studio, but then this

//# Something like this ...

would then be parsed and returned as

Something like this

...

Even copy/pasting could be an event trigger.

— Reply to this email directly or view it on GitHub https://github.com/jhipster/jdl-studio/issues/3#issuecomment-194780681.

MathieuAA commented 8 years ago

I see where you're right about UML editors, it's absolutely true. The truth is that we heavily depend on UML editors, and if we depend on the studio, then we'd have to change every time the studio does (or when one of its dependency changes). The JDL isn't supposed to have in its syntax anything far from JHipster (i.e where the '#' comes from). That's why the JDL parser exist: to give the user a choice between UML editors or something closer to JHipster, something that doesn't depend on anything except the JDL. Be that as it may, the studio will depend on the JDL, as there's a JDL project now.

deepu105 commented 8 years ago

common man JDL studio is part of Jhipster as well and it will change only if there is a need in Jhipster.

And you would never have to actually change becoz of this coz you are not gonna add a dependency or anything and the lines of code I gave above will not cause any issues even If something changes in the studio.

My aim here is to provide our users a seamless experience and workflow

MathieuAA commented 8 years ago

I know it is, and I wouldn't have it another way. To ignore '#', you'd have to create your own JDL parser (there's one for JHipster UML because we use an intermediary data representation, and it will be moved as soon as the JDL is removed from JHipster UML). Or, use the solution I proposed earlier. Even the parser factory would have to change because the JDL is too deeply embedded into JHipster UML, and as there's a new project...

We could just see what needs to be moved to the new project, and figure out an easy way to make everyone happy.

deepu105 commented 8 years ago

If you are gonna regenerate the parser it would be nice if you can just ignore the lines with # coz the other solution you suggested is hacky and still not great in terms of data integrity of files.

Also i was doing the sub generator and found that jhuml current master broke the way jdl was being processed. Any way ill open a ticket there to discuss that On 10 Mar 2016 19:24, "Mathieu ABOU-AICHI" notifications@github.com wrote:

I know it is, and I wouldn't have it another way. To ignore '#', you'd have to create your own JDL parser (there's one for JHipster UML because we use an intermediary data representation, and it will be moved as soon as the JDL is removed from JHipster UML). Or, use the solution I proposed earlier. Even the parser factory would have to change because the JDL is too deeply embedded into JHipster UML, and as there's a new project...

We could just see what needs to be moved to the new project, and figure out an easy way to make everyone happy.

— Reply to this email directly or view it on GitHub https://github.com/jhipster/jdl-studio/issues/3#issuecomment-194799578.

MathieuAA commented 8 years ago

For me, the most logical solution would be to modify the export/import functions, but I already said that. We have to precisely know what will be included in the JDL project so as to come out with the best solution (or at least a set of good solutions) for this problem.

deepu105 commented 8 years ago

yes but since both are projects under the same hood trying to get the best workflow for a user I dont find it as a problem at all. I would do it in place which gives best user experience. Ill open a ticket in the JDL project to discuss how the JDL module should be

deepu105 commented 8 years ago

This is done in jhipster/jhispter-core which will be soon used by all projects to parse JDL and this should be fixed when its released. Hence closing this as there is nothing to be done in this project for this