Allow customization of the field type in jdl

[nicolas63]

Overview of the feature request

Today only java field type is valid in jdl. For the blueprints like dotnet the ideal would be to be able to have its own field type.

I can help on this issue but I would need someone to guide me through it.

Motivation for or Use Case

it is difficult to ask a dotnet developer to think with java types.

Related issues or PR

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

example :

JDL with java type

/**
 * The Employee entity.
 */
entity Employee {
	/**
	* The firstname attribute.
	*/
	firstName String,
	lastName String,
	email String,
	phoneNumber String,
	hireDate Instant,
	salary Long,
	commissionPct Long
}

JDL with dotnet type

/**
 * The Employee entity.
 */
entity Employee {
	/**
	* The firstname attribute.
	*/
	firstName string,
	lastName string,
	email string,
	phoneNumber string,
	hireDate DateTime,
	salary long,
	commissionPct long
}

[mshima]

I understand your point, but I don't think we should add support to this.

• It's not so simple as adding support to jdl. The generators use those types to convert to specific type: frontend: Long => number, String => string. liquibase: Long => bigint
• It would make jdl technology specific. One beauty of jhipster is to take 1 jdl and try many technologies.

JHipster types happens to be Java type because it's the main backend technology.

The only way I think it could be implemented is to make jdl extensible, so it would convert from string to String so frontend generators would work, but it should be a LOT of work. You would have to fork the entire jdl stack like official docs, jhipster-base, jdl-frontend-plugin.

[nicolas63]

I understand the difficulty but do you think there is no way to do it without fully fork jdl stack ? I think this would greatly contribute to the adoption of non-java blueprints

[MathieuAA]

Hello there. I'm currently toying something that could help making the JDL language/tool agnostic. It's still in development though.

I'll comment this issue if and when my experiment is sufficiently advanced.

[nicolas63]

Hello there. I'm currently toying something that could help making the JDL language/tool agnostic. It's still in development though.

I'll comment this issue if and when my experiment is sufficiently advanced.

Awesome :grinning: , if you need help in any way, I'm here.

[MathieuAA]

For now I'm starting with application configuration options, field types with validations, and options. Then, I'll add support to relationship changes.

My plan is to provide a simple interface where JDL import can be modified during validation.

This implies modifying the parsing phase a bit.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[nicolas63]

Comment to take open

[nicolas63]

For now I'm starting with application configuration options, field types with validations, and options. Then, I'll add support to relationship changes.

My plan is to provide a simple interface where JDL import can be modified during validation.

This implies modifying the parsing phase a bit.

@MathieuAA Have you made any progress on this ? Can i help you ?

[MathieuAA]

I'm lacking time to properly develop it. I'm nearly done though.

[nicolas63]

Oh nice, if you need feedback or test don't hésitate to ping me

[MathieuAA]

Work is being done there: https://github.com/MathieuAA/generator-jhipster/tree/custom-jdl-props

It involves passing custom properties to the JDL importing object. For instance, if one wants to have custom types, field validations, new options and/or values, application option and/or values, this would be the way to go.

Here's the current interface I'm working on:

 {
    noCustomProperties: Boolean,
    applications: {
        options: {
            validationRules: ( (Map<ApplicationOptionName, ApplicationOptionValues>) => void )[],
            <EXISTING_OPTION>: { // such as baseName, etc.
                additionalValues: String[]
            },
            <NEW_OPTION>: {
                type: String, // either string, boolean, integer or list
                possibleValues?: String[]
                defaultValue?: String
            }
        }
    },
    entities: {
        fields: {
            types: {
                validationRules: ( (Map<FieldTypeName, FieldTypeProperties>) => void )[],
                <EXISTING_FIELD_TYPE_NAME>: { // such as String, etc.
                    validations: {
                       <VALIDATION_NAME>: {
                            type: String, // either string, boolean, integer or list
                        }
                    }
                },
                <NEW_FIELD_TYPE_NAME>: {
                    validations: {
                        <VALIDATION_NAME>: {
                            type: String, // either string, boolean, integer or list
                        }
                    }
                }
            }
        }
    },
    options: {
        validationRules: ( (Map<OptionName, OptionValues>) => void )[],
        <EXISTING_OPTION>: {
            additionalValues: String[]
        },
        <NEW_OPTION>: {
            type: String // either 'unary' or 'binary'
            possibleValues?: String[]
        }
    }
}

and a part of the comment:

 * Creates custom properties to be taken into account when parsing and importing a JDL content.
 * One can also pass custom validation rules to forbid mixing options, or enforce them. These functions can either throw
 * or just be executed without error.
 * One can also set the noCustomProperties, meaning there isn't any new custom property (instead of no value at all).

I haven't added deployment custom options yet (I know Pierre wanted them ;))

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[MathieuAA]

Nop, keep it open

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[nicolas63]

Can you reopen this issue please ?

[nicolas63]

thanks

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

[nicolas63]

thanks @pascalgrimaud to reopen this issue, I am very interested to have this feature for the dotnet blueprint

[pascalgrimaud]

No problem, it's an auto reopen for all stale tickets Not sure if someone wants to work on this

[DanielFran]

@mshima @nicolas63 Can you confirm this can be closed now that blueprint has been migrated to v8?

[mshima]

@mshima @nicolas63 Can you confirm this can be closed now that blueprint has been migrated to v8?

No.

I think if implemented should be implemented like we did for configs.

application {
  config {
    baseName jhipster
    blueprints [dotnetcore]
  }

  config(dotnetcore) {
    clientFramework blazor
  }

  entities *
}

entity(dotnetcore) Foo {
  name string
}

[github-actions[bot]]

This issue is stale because it has been open for too long without any activity. Due to the moving nature of jhipster generated application, bugs can become invalid. If this issue still applies please comment otherwise it will be closed in 7 days