More advanced enums in JDL

[62mkv]

Overview of the feature request

Currently, (I know of) only one simple way to define Enums, like:

enum EnvironmentType {
  ARCHIVE, DEV, INTEGRATION, PROD, TEST, UAT, NON_PROD
}

I would suggest to add a way to define custom text for each value like

enum EnvironmentType {
  ARCHIVE("archive"), DEV("development"), INTEGRATION("integration"), PROD("production"), TEST("test"), UAT("uat"), NON_PROD("non-prod")
}

Motivation for or Use Case

This is the way it's done idiomatically in Java, so when you try to update the generated enum.java file with such information, it all gets lost after regenerating from JDL (whenever you've added or updated any enum value name), so it's very annoying.

The generated enum might look like this:

public enum EnvironmentType {

    ARCHIVE("archive"),
    DEV("development"),
    INTEGRATION("integration"),
    PROD("production"),
    TEST("test"),
    NON_PROD("non-prod"),
    UAT("uat");

    private String naturalName;

    EnvironmentType(String naturalName) {
        this.naturalName= naturalName;
    }

    public static EnvironmentType fromNaturalName(String naturalName) {
        for (EnvironmentType value : EnvironmentType.values()) {
            if (value.getNaturalName().equalsIgnoreCase(naturalName)) {
                return value;
            }
        }
        return null;
    }

    String getNaturalName() {
        return naturalName;
    }
}

I am not sure what could/should be done on the frontend side when enum is defined like that

Related issues or PR

• [x] Checking this box is mandatory (this is just to show you read everything)

[gmarziou]

when you try to update the generated enum.java file with such information, it all gets lost after regenerating from JDL (whenever you've added or updated any enum value name), so it's very annoying.

Isn't it mostly covered by git merging ?

[62mkv]

@gmarziou what do you mean by that? I understand that one might 'mitigate' to a certain degree havoc wroken by re-generation, by using VSC tools, but it's a hack, so why not at least try to minimize damage?

[62mkv]

although admittedly, this is just one of the many many cases you might want to do with enums, and also it belongs into different repo, apparently (jhipster-core) but I would be interested in core maintainers thoughts on this issue

[amatosg]

take in consideration having ARCHIVE(1), (integers instead of string)

[MathieuAA]

@amatosg that's an unexpected side-effect and this "support" isn't guaranteed, so beware.

Frankly, I'm in favor of adding this as a feature as:

• it's a common use case
• I don't expect it to be too difficult a task
• it resolves the original issue
• it describes the object (which is what the JDL is for)

[deepu105]

You are the boss here Mathieu, so if you think it's fine then it's good. On a side note, this could also be a JDL only feature. As we are planning to go JDL centric we can add more features to JDL and have the entity sub generator only support simple cases. Ofcourse the fetaure needs to be implemented in the generator but it doesn't have to be supported in the entity sub gen prompts.

Thanks & Regards, Deepu

On Sat, Jun 22, 2019 at 8:41 PM Mathieu ABOU-AICHI notifications@github.com wrote:

@amatosg https://github.com/amatosg that's an unexpected side-effect and this "support" isn't guaranteed, so beware.

Frankly, I'm in favor of adding this as a feature as:

• it's a common use case
• I don't expect it to be too difficult a task
• it resolves the original issue
• it describes the object (which is what the JDL is for)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/9940?email_source=notifications&email_token=AAIOKF524MPKBKYSVSKBYQLP3ZW6RA5CNFSM4HZHFFVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYKPFJA#issuecomment-504689316, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIOKF2Y5NJXQDQBJOXQHELP3ZW6RANCNFSM4HZHFFVA .

[amatosg]

@amatosg that's an unexpected side-effect and this "support" isn't guaranteed, so beware.

I don't understand what do you mean by that. In any case, I didn't meant integer instead of string, I was trying to say also strings. Sorry for the confusion.

[gilbriatore]

It is possible to generate a enum like this in jdl/jhipster?

enum Estado { AC("Acre"), AL("Alagoas"), AM("Amazonas"), AP("Amapá"), BA("Bahia"), CE("Ceará"), DF("Distrito Federal"), ES("Espírito Santo"), GO("Goiás"), MA("Maranhão"), MG("Minas Gerais"), MS("Mato Grosso do Sul"), MT("Mato Grosso"), PA("Pará"), PB("Paraíba"), PE("Pernambuco"), PI("Piauí"), PR("Paraná"), RJ("Rio de Janeiro"), RN("Rio Grande do Norte"), RO("Rondônia"), RR("Roraima"), RS("Rio Grande do Sul"), SC("Santa Catarina"), SE("Sergipe"), SP("São Paulo"), TO("Tocantins") }

When I try to run jphipster I get this error:

Error during import-jdl: Error: MismatchedTokenException: Expecting token of type --> NAME <-- but found --> '"

[ruddell]

@gilbrilhador This works as expected with generator-jhipster v6.9.x, and fails with v6.8.x, so it was fixed sometime between those versions

[gilbriatore]

Thank you @ruddell !!! I'm with version 6.8.0... I'll try to update.