As asked by maling at https://github.com/abpframework/abp/issues/22988, hereby my feature request via a support ticket:
It is not about a question or problem, but reflects a feature request. I don't know the consequences in terms of money for my situation, but hopefully a feature request doesn't get billed or put down my ability to ask questions (I see I can ask 5 questions with my account?).
Copy-paste from GitHub:
Is your feature request related to a problem? Please describe the problem.
I have created a 'Status' field (integer) in one of my projects. I don't want this field to be reflected by a database table. I would rather like to create an enumeration for the values of that field and use that field in my front-end. The value of this approach is that it doesn't add unnecessary database tables and adds a typed value to my code in the domain, which makes the logic inside my domain objects more readable and intuitive and doesn't clutter the database.
Describe the solution you'd like
In my opinion it could be relatively easy to implement, for example when adding a property of type int in Abp suite, an option to generate an enum is shown. If checked, the values and reflecting text can be added (i.e: 1 - Concept, 2 - Published, 3 - Deprecated). The suite then generates the enumeration, and instead of adding an integer field to the entity, it adds an enumeration field to the entity. This could also be reflected in the DTO's and lastly in the front-end (with a dropdown element i.e.).
Additional context
Now, I've added the enumeration myself in Domain.Shared and use it to add an extra property to my Entity. I've given it an [NotMapped] attribute (so the generated code doesn't break on runtime because of the mapping from the database to the entity fails). This extra property only translates the existing integer field to the enumeration status like this:
[NotMapped] public ImpactConfigurationStatus Status { get => (ImpactConfigurationStatus)ImpactConfigurationStatus; set => ImpactConfigurationStatus = (int)value; }
I've also added these properties (without the attribute) added to the DTO's.
In the front-end something like this could be added automatically:
private IEnumerable<KeyValuePair<int, string>> GetStatusItems() { return Enum.GetValues(typeof(ImpactConfigurationStatus)) .Cast() .Select(e => new KeyValuePair<int, string>((int)e, L[$"Enum:ImpactConfigurationStatus:{e}"])); }
And in the front-end pages, replace the default element for an integer with a dropdown element (in the create modal, the update modal, the filters).
And lastly, as in the last code-block, it should also be relatively easy to make the values localisable.
3 Answer(s)
-
0
Hi, thanks for the feature request! We've created an internal issue to track it and will include it in our planning.
Best regards.
-
0
Thanks! Would add a lot of value and is complementary to the BookStore example (BookTypes) provided by ABP :)
-
0
[jmvvliet] said: Thanks! Would add a lot of value and is complementary to the BookStore example (BookTypes) provided by ABP :)
I agree, it's a great feature that fits well with the BookStore example and how BookTypes are used. It will definitely add value. Thanks again for the suggestion!
