Hola, no se cómo realizar la pregunta para que sea lo más clara posible, pero voy a intentarlo.
Estoy desarrollando un sistema donde se crearán algo así como diferentes tipos de contenidos: se agregan, se quitan, se modifican los campos, etc. Como verán no es conveniente estar haciendo entidades para manejar estos formularios.
¿Existe algún componente que dibuje los formularios dependiendo de los campos de una tabla en la base de datos, sin mayor configuración?
Gracias.
Respuestas
Lo primero que te diría es que dar "infinita" libertad al usuario para crear cualquier formulario que incluya cualquier tipo de campo es algo bastante complejo técnicamente. Las soluciones que he visto para resolver esto han sido:
- Guardar en la base de datos por un lado la estructura del formulario en formato XML o JSON y por otro los datos serializados de cada "entidad".
- Utilizar una simple tabla clave: valor para permitir definir un número indeterminado de campos en cada formulario.
La segunda opción es mucho más sencilla. Sería algo así:
Tabla: items id (autoincrement) titulo etc. Tabla: campos id (autoincrement) item_id clave valor Tabla: valores id (autoincrement) item_id clave valor
Así en la base de datos tendrías información como esta:
Tabla: campos (en este caso, valor es el tipo de campo de formulario) | id | item_id | clave | valor | | ----| ------- | -------- | ------ | | 1 | 1 | 'nombre' | text | | 2 | 1 | 'precio' | text | ... Tabla: valores (en este caso, valor es el valor asignado al campo de formulario) | id | item_id | clave | valor | | ----| ------- | -------- | ------------------- | | 1 | 1 | 'nombre' | 'Lorem ipsum ...' | | 2 | 1 | 'precio' | 19.99 | ...
WordPress por ejemplo usa esta estrategia para guardar los metadatos de los comentarios, posts, etc. Aquí puedes ver el esquema de base de datos de WordPress.
@javiereguiluz
Hace bastante tiempo implementé un CMDB donde los campos de cada registro tenían que ser dinámicos tal y como perfectamente te has explicado.
A priori utilicé la solución 1 con datos serializados (tratando incluso de implementar la solución con MongoDB), sin embargo la complejidad aumentó exponencialmente cuando quise hacer que esos campos pudieran ser relaciones con otras tablas, así que me decanté por la segunda opción y descartando nosql.
También me gustaría saber si existe un marco de trabajo de referencia para este tipo de sistemas.
@KePitt2