Dynamic Attributes for an Entity

3
I would like to explore options for changing the names of entities and their associated attributes within a deployed application (i.e. via an admin portal). One solution I thought requires the modeler to know the number of entities and the number of attributes. Two tables for each entity would be created: Table 1 - Admin Table - Attributes would be labeled "TableName", "AttributeName1", "AttributeName2", etc., allowing the user to enter a string value for the real name. A boolean value as to whether the attribute should be displayed (i.e. "ShowAttribute1", "ShowAttribute2") is also required (set to false as a default to hide all the attributes unless they are turned on). Table 2 - Data Table - Attributes would be labeled "Attribute1", "Attribute2", etc. The associated forms to capture and display the data would use the attribute name from the Admin table; attributes would be conditionally visible based on the boolean value as to whether that attribute should be displayed ("ShowAttribute1", etc.). Unfortunately this would need to be done within a data view, not a data grid, since the condition must be placed on a row (not a column) and captions within a data grid cannot be dynamic. Obviously you at least need to know the number of entities to create the associated forms, then you could just create some number of attributes which is larger than you ever plan to reach to account for the fact that you do not know how many attributes the administrator will setup. Is there another way to accomplish this? It's basically designing the domain model within the application, not in the modeler! The reasoning provided by the customer is that the "administrator" can make the changes without having to go back to the "modeler" to redeploy the model.
asked
3 answers
1

I have done something similar in another platform. Basically you are just creating another meta-data layer to control field labels and which fields to display for each form. I would suggest you do this at the form level, rather than the entity level, as then you can have several forms for the same entity with different attributes displayed, all controlled by data. It's still going to be difficult to have a good looking UI form unless you have a really simple layout.

answered
1

As Sander indicates, this is possible, but you need to step up a level of abstraction, and forms need to be generic, so i think it has in general limited usefulness. The domain model then would look like the one provided by the model reflection module. You need to have something like:

EntityType (name : String)
AttributeDefinition (name: String, type: String, owner: EntityType)
Instance (entityType : EntityType)
Attribute(instance : Instance, attributeType : AttributeDefinition, value : String)

Associations can be modeled in a similar fashion.

DISCLAIMER

Off course, this approach would be many times harder to maintain then 'going back' to the modeler. Using this approach means: No Meta model validations, no keeping data on migration, no designing forms etc. It can be done, but i would advice very strong against it, unless you have a really specific purpose and limited functionality with such a model, and no requirements concerning usability/ the GUI. Sooner or later your client will ask to be able to click through on an attribute to open a form and you are hacking for hours for something which could done in 2 clicks in the modeler. No more agility. I think it is interesting to find out why the client is asking for such functionality?

Off course, if he would like to edit any data in a generic way, and modify any entity/ attribute definition, you could deliver the appropiate database client, for example PgAdmin ;)

answered
0

Michel,

Good advice. I am leaning toward just making this work in the modeler. I have only 93 different tables and I am not willing to create dozens of microflows and make all sorts of complexity. I will take the advice very seriously, thanks.

jeff

answered