Lanzado en 4D v18, la arquitectura proyecto es una evolución importante para las bases 4D. Un proyecto está hecho de archivos de texto legibles por humanos y permite que su código 4D se beneficie del poder de las herramientas de control de código fuente. Además, la arquitectura proyecto soporta de forma nativa las librerías e interfaces más modernas.

Para una discusión exhaustiva sobre proyectos, consulte developer.4D.com.

Puede convertir una base binaria 4D (archivo .4db) en un proyecto, utilizando un simple comando de menú de su aplicación monousuario 4D. Debido a que la exportación solo crea una nueva versión de la base existente, los archivos originales nunca se tocan. Por lo tanto, puede convertir su base tantas veces como lo necesite hasta que esté satisfecho con el resultado. Abra su base de datos .4db, realice algunos cambios, luego conviértala de nuevo y pruebe los resultados. Cada nueva conversión reemplaza a la anterior.

Tenga en cuenta que una exportación es una operación unidireccional:

• Una vez que se ha exportado una base 4D como proyecto, ambas versiones se vuelven independientes.
• Un proyecto no se puede exportar a un archivo .4db   
• Como los proyectos dependen de la mayoría de las tecnologías modernas, no soportan algunas funcionalidades heredadas. Estas funcionalidades se actualizan automáticamente si es posible o generan errores de conversión (ver más abajo).

Cuando convierte una base 4D existente en un proyecto, el archivo .4db no se modifica: se crea una carpeta llamada "Proyecto" junto a su archivo .4db, y contendrá todos los archivos necesarios.

Nota: si ya existe una carpeta llamada "Proyecto" en el mismo nivel que su archivo .4db (por ejemplo, si ya se realizó una conversión), será reemplazada por el proceso de conversión.

Para convertir una base de datos a un proyecto:

1. Abra la base de datos a convertir.
2. Seleccione Archivo > Exportar > Estructura para proyecto.
   

Notas:

• Esta opción de menú sólo está disponible en 4D monopuesto.
• Este comando solo está disponible si una base binaria está abierta; está deshabilitada en las bases proyecto.
• También puede utilizar el comando .

Si la conversión es exitosa y no se encuentran errores de bloqueo, se muestra el siguiente diálogo:

• Revelar historial: resalta el archivo de historial de conversión en su disco. Es muy recomendable leer este archivo, ya que el proceso de conversión podría haber modificado algunas partes de la aplicación (ver abajo la sección Marcar la conversión).
• Abrir proyecto: reinicia la aplicación 4D y carga el proyecto convertido.

El archivo de datos no se ve afectado por la conversión. Solo se convierten los elementos de desarrollo. Aún puede abrir el archivo de datos con el archivo de estructura .4db después de una conversión.

Además, los recursos, los registros o las carpetas web de .4db son utilizados automáticamente por el proyecto, sin modificaciones. Esto facilita la conversión y prueba de su proyecto.

Durante la conversión, se crea una nueva carpeta "Proyecto" en el mismo nivel que su archivo de estructura .4db. Contiene todo el desarrollo de su aplicación como archivos de texto: formularios, estructura, métodos, disparadores, menús, consejos, listas. También contiene un archivo .4DProject, que es el archivo principal del proyecto 4D convertido:

Cuando abre el archivo .4DProject con su aplicación 4D, el proyecto utiliza la misma carpeta de recursos y carpeta web que el archivo .4db existente, lo que facilita la prueba de su proyecto.

Aún puede abrir la base .4db, realizar modificaciones si es necesario (ver abajo), luego exportarla nuevamente y probarla. Puede repetir esta operación hasta que esté satisfecho con la conversión.

Se crea un archivo de historial en formato JSON de forma predeterminada durante el proceso de conversión para hacer referencia a todos los problemas que requieren una acción del convertidor. En este archivo, los mensajes se clasifican en tres categorías (propiedad "severity"), por ejemplo:

• info: describe una acción necesaria ejecutada automáticamente por el convertidor que no tendrá un impacto en la interfaz o las funcionalidades de la aplicación. Por ejemplo, si tiene imágenes en la librería de imágenes, 4D las exporta a la carpeta Recursos de la base (ver el ejemplo anterior).

• advertencia: describe una acción necesaria ejecutada automáticamente por el convertidor que podría generar diferencias en las funcionalidades o la interfaz de la aplicación, pero sin impedir que se ejecute la base. Las advertencias generalmente requieren que controle el impacto de la conversión en su código. Por ejemplo, se devuelven advertencias cuando las configuraciones de compatibilidad no soportadas se cambian automáticamente, como "Modo Unicode" o "Botones de radio agrupados por nombre" .

• error: describe un problema que requiere que se corrija su intervención. Puede evitar que la base se ejecute correctamente. Por ejemplo, algunos objetos de formulario heredados ya no son compatibles, como los botones resaltados. En este caso, debe convertir el botón usted mismo en un botón 3D en el archivo .4db antes de reiniciar la operación de conversión.

Cuando se requieren ediciones en la base .4db, simplemente modifique el código o el formulario en consecuencia y exporte la estructura nuevamente. Repita según sea necesario hasta que esté satisfecho con el resultado.

Durante la conversión, algunas tecnologías 4D heredadas se convierten en implementaciones más modernas, y algunas otras se modifican o se ignoran. En particular:

• La librería de imágenes ya no existe en los proyectos. Durante la conversión, 4D exporta todas sus imágenes a la carpeta Recursos de la base.
• Los objetos de formulario y las propiedades de objeto de formulario se han actualizado (ahora utilizan la misma gramática que Formularios dinámicos). Las partes en desuso no son soportadas.
• Las subtablas (obsoletas desde 4D v11, ver Subtablas) no están soportadas en los proyectos.
• Los grupos anidados de objetos de formulario no son soportados en proyectos (los grupos se implementan en un solo nivel de objetos). Durante la conversión, los grupos anidados se extraen hasta el nivel más bajo.
• La propiedad Tabulable no se soporta en proyectos porque el orden de entrada es administrado por la colección entryOrder en Formularios dinámicos. Durante la conversión, la colección se llena automáticamente con respecto a la configuración del orden de entrada existente (capas de objetos y propiedades tabulables). Puede verificar en la base de datos del proyecto que el orden de entrada del formulario se convirtió correctamente.
• Los parámetros de compatibilidad de la base se reinicializan como para una nueva base. Consulte el archivo de registro de conversión para verificar el estado de la configuración de compatibilidad para su base.
• Todas las opciones de compatibilidad de los formularios (por ejemplo, "Ajuste dinámico", "Con restricciones") se reinicializan como un nuevo formulario.
• Las hojas de estilo se exportan como hojas de estilo CSS en los archivos JSON almacenados en la carpeta "/SOURCES" llamada:
  • "styleSheets_mac.css" para macOS,
  • "styleSheets_windows.css" para Windows.
    
    Las hojas de estilo aplicadas se agregan como atributos "class" para formar las descripciones de objeto JSON.
• Los objetos formulario se expanden automáticamente hacia abajo cuando el tamaño de la fuente CSS o de la plataforma es demasiado grande. Esto evita que el texto se trunque.
• La visibilidad de los marcadores de control de salida no se conserva al cerrar y volver a abrir formularios en proyectos.
• Los comentarios del explorador se exportan como archivos de documentación markdown (texto sin formato). Consulte developer.4d.com para más información sobre los archivos de documentación markdown.

Los siguientes objetos y propiedades de formulario no cumplen con los requisitos actuales de la interfaz y ahora están en desuso. No se soportan en Formularios dinámicos, y podrían generar una advertencia o un error en el archivo de registro de conversión del proyecto (ver comentarios).

La renderización de objetos de formulario puede ser diferente en los proyectos cuando se utilizan comandos de formato con parámetros predeterminados o faltantes.

Las siguientes opciones de estructura de la base de datos están en desuso y se editarán o generarán errores en el archivo de registro de conversión del proyecto (ver comentarios).

Los siguientes editores y funcionalidades de Caja de herramientas están en desuso y no son soportados en proyectos:

Durante la conversión, los usuarios y grupos 4D existentes se extraen automáticamente del archivo .4db y se almacenan en el archivo directorio.json para el proyecto.

En los proyectos, dado que el código se almacena en archivos de texto de formato abierto, la gestión de acceso de usuarios 4D funciona de manera diferente que en las bases binarias. En particular:

• en modo monousuario, el sistema de contraseña siempre está deshabilitado:
  • el diálogo de inicio de sesión nunca se muestra,
  • el usuario actual siempre es el Diseñador,
  • la configuración para el servidor SQL o el servidor web se ignora (pero se puede configurar para la implementación cliente/servidor).
• no hay diferencia entre los usuarios creados por el Diseñador o el Administrador.
  
• no es posible asignar un grupo de acceso o un grupo de propietarios a menús, métodos y formularios. La protección del código debe manejarse a nivel de la herramienta de control de fuente.
• las ID de usuario y grupo (referencias) se administran dinámicamente durante la sesión, sin embargo, no se almacenan.
  

En el modo cliente-servidor, el control de acceso del usuario funciona tanto en bases proyecto como en bases binarias. Sin embargo, la asignación de grupos a menús, métodos y formularios no es soportada (ver la notas de seguridad).

En consecuencia, después de la conversión:

• El tipo de usuario "Desarrollador" ya no existe, todos los usuarios (excepto el Diseñador y el Administrador) tienen el tipo "Usuario".
• El tipo de grupo y los propietarios del grupo se eliminan.
• Las ID de usuario estáticas y las ID de grupo no se guardan, excepto el Diseñador (ID=1) y el Administrador (ID=2).
• En el historial de la base, la información "user4D_id" se reemplaza por "user4D_alias", que es el alias de usuario 4D (nombre de usuario 4D si no se definió ningún alias).

Las librerías de objetos personalizadas existentes (.4il en Windows o .4dlibrary en macOS) deben exportarse por separado si desea utilizarlas en sus proyectos. Para más información, consulte esta publicación de blog dedicada. 

La estrategia de despliegue de proyectos 4D se basa en archivos.empaquetados 4dz, donde toda la estructura es de sólo lectura. Este es el caso de las aplicaciones fusionadas, o de los componentes compilados. En consecuencia, los comandos que modifican la estructura no funcionarán y no deben ser utilizados en las aplicaciones desplegadas. Si se llaman, no harán nada, o lanzarán un error, dependiendo del contexto.

Tenga en cuenta que no se recomienda modificar los archivos de estructura en las aplicaciones desplegadas por las siguientes razones:

• impide la instalación de aplicaciones fusionadas en carpetas de Aplicaciones estándar, en las que los usuarios a veces no tienen derechos de escritura
• rompe la firma de las aplicaciones firmadas, en cuyo caso el SO puede considerar que han sido infectadas
• hace que la actualización de las versiones de la estructura desplegada sea muy compleja cuando hay que guardar las modificaciones locales.

Sin embargo, si es absolutamente necesario evitar el formato .4dz y mantener la carpeta "Proyecto" tal cual, para poder modificar sus archivos fuente en los sitios desplegados (lo cual no es recomendable, como se explicó anteriormente), puede interesarle la llave PackProject . 

Aquí está la lista de comandos que modifican la estructura:

Cuando una base se convierte en un proyecto, se reinicia el contador de archivos de backup. Esto significa que el primer archivo de copia de seguridad de un proyecto convertido se llamará miBase-0001, sea cual sea el número de secuencia del último archivo de la base de datos binaria.

En realidad, el contador de archivos de copia de seguridad está vinculado al archivo de estructura de la base de datos. Cuando renombra o mueve un archivo .4DB, y más aún cuando lo convierte a un .4DProject, se inicia un nuevo contador de copias de seguridad.

Una vez que esté satisfecho con su base de datos convertida y desee comenzar a trabajar en su proyecto, puede limpiar su directorio de trabajo:

1. Elimine sus archivos .4db y .4dindy de la carpeta de la aplicación (por ejemplo, muévalos a un directorio de respaldo). En macOS, es posible que deba utilizar de antemano el comando Mostrar paquete o eliminar la extensión .4dbase (ver a continuación).
2. En macOS, elimine la extensión de carpeta .4dbase durante toda la fase de desarrollo. Como va a trabajar con archivos de texto y colocarlos bajo una herramienta de control de código fuente, necesitará tener acceso directo a ellos.

Si desea que el archivo de datos se abra automáticamente después de que el proyecto se mueva a otras máquinas, puede hacerlo compatible con la arquitectura del proyecto, como se describe en developer.4d.com:

1. Cambie el nombre de su archivo de datos "data.4dd".
2. Cree una carpeta llamada "Datos" y mueva el archivo data.4dd dentro de esa carpeta
3. Almacene la carpeta Datos en el mismo nivel que la carpeta Proyecto.