I would like to be able to use the app's programming language to
dynamically create classes that match our form models, but I do not
consider a good practice do to so. On the other hand, I don't think it
is smart either to recreate OOP at a higher level of abstraction ...
The idea isn't new. In Java, we have libraries addressed to create classes from scratch in runtime and once created they work as they had been in the classpath since the starting of the application. I find this kind of things amazing and I would definitively consider implementing solutions as the one suggested, but IMO, the cons outweigh the pros.
For the sake of the answer, I won't go deep into details but some of the cons I see are:
- The impact on the memory
- Sizing the memory requirements
- Application behaviour predictability
- Debugging and error solving
- Hard to reason about
- Hard to integrate with frameworks and libs
- Goal deviation
I find the solution to be sophisticated but makes my life a bit harder. Developing this approach is not trivial and probably will deviate my attention to something different than solving the main problem: Making dynamic forms for my CRM.1
how, at developer-level, can we represent the form model
Document <|--- Form <>----- Field
Form are logical models or metamodels, whatever you like more.
- is not a model per se
- it is not a type
- it's an instance of my logical model.
- It's a
Document. More precisely, a
Note: I have pictured Form as an aggregation of fields. It could also be a composition of fields. Or a mixup, why not?
Basically, there's only one model
Document which "type" varies from instance to instance. Regardless of the composition, all the instances are
MetaData is important because it completes the definition of each node of the
Documentat the document itself. For example, it has the name of the document, the target, method and validations of the form, the value range or the data source of the field, the placeholder, the default value, etc
Document ensures the invariants for any instance of
Document (meta is not null, has a name, etc),
Form ensures the invariants for any instance of
Form (MyForm has fields, has a name, has a target, has a method, etc).
Later, you can persist/map instances of the metamodel as you wish. As JSON, as an XML or as rows in any RDMS. It should be easy to integrate with your favourite ORM or mapper too, somethin I presume that is not going to be so simple with classes created and compiled in runtime.
1: A premise to me is that the complexity of a solution should proportional to the complexity of the problem is solving. If the problem was making a framework for many and different types of applications, I would consider creating classes in runtime. But it's not the case.