Sometimes, the name we want to display on the front-end differs from the name that the field should have in the backend. JDL should support the ability to supply a friendly name for an entity or a field, and use the friendly name for all user-visible content (HTML, etc.) and use the logical name (what we currently have) for all coding purposes.
Character (a Role Playing Game has entities called "characters" that are playable actors/people in the game.) Instead, some other name has to be given in the entity JDL; currently this logical name is interpreted to create the UI, which ends up in the UI having the wrong names and having to be manually edited.jdl-import, or else allow it to overwrite and then re-make the changes.chr (as someone familiar with the app, it's not hard to guess what that means), but you want the user to see a page letting them edit Characters, not Chrs.Here is example, hypothetical JDL for what I'd like to do:
entity Chr as "Character" {
str String required as "Name"
}
entity B { }
relationship OneToOne {
Chr{b} to B{chr(str) as "Character Name"}
}
In code, the DTOs, services, domain model, etc. would include the logical names just like JDL currently does. In anything the user can normally see in the front-end (client code), the string in quotes after as would be used instead, without any casing interpolation or auto space insertion (just take the value literally, so abcdEfgh would not render as Abcd Efgh, but as abcdEfgh.)
Latest stable 4.x
We spoke in the Gitter chat. While you can't use Java/Angular reserved words in entities (like char), you can use reserved database words in tables like Character by customizing the table name:
entity Character (jhi_character) {
name String
}
I don't think there's enough added-value for the extra entity fields and work this would take to maintain. I recommend that you create a separate UI for users to interact with (copying code is fine).
Slightly off topic, but one way we could improve the JDL experience is to allow importing a single entity from a JDL file. Currently the developer is forced to go through each entity's conflicts every time any entity is changed via JDL
Actually I think it might be useful to have a display name option atleast via JDL. In terms of maintenance this shouldn't be too much as we already use a different variable internally for display name so that we could use jhiPrefix. So it might be easy to hook this up to that actually. So I'm actually inclined to do this. What do you think @jdubois @MathieuAA ?
@ruddell I think if a jdl has changes only in one entity then others will not regenerate. So behaviour should be same as you expected. This was working like this I checked last. Can you check again?
@deepu105 Testing with two entities, when I make UI changes for EntityOne and JDL changes for EntityTwo, importing the JDL regenerates both EntityOne and EntityTwo and prompts to overwrite the UI changes
entity EntityOne {
name String
}
entity EntityTwo {
name String
}
Even if I import a separate JDL file that only has EntityThree in it, all three entities are regenerated.
Note that entities also have a pluralized form
Good idea. If it gets supported by the generator one day, I don't see why not.
The only change I'd make to the proposed form of this feature is:
entity Chr (table_name) {
someName String required as Name // without quotes
}
So a few wrinkles so far:
I would also like to add the "business type" of data, so we can use https://github.com/marak/Faker.js/ to generate fake data.
My main issue is that if we add too many of those, it's going to be very complex to maintain
Seems like a lot of work, and nobody has started anything on this during the last month, I'm closing this for lack of interest.