Lançado em 4D v18, a arquitetura projeto é uma evolução importante para os bancos de dados 4D. Um projeto está feito de arquivos de texto legíveis por humanos e permite que seu código 4D se beneficie do poder das ferramentas de controle de código fonte. Além disso, a arquitetura projeto é compatível de forma nativa com as bibliotecas e interfaces mais modernas.

Para uma discussão exaustiva sobre projetos, consulte developer.4D.com.

Pode converter um banco de dados binário 4D (arquivo .4db) em um projeto, utilizando um simples comando de menu 4D. Como a exportação apenas cria uma nova versão do banco de dados existente, os arquivos originais nunca são modificados. Portanto, pode converter seu banco tantas vezes quantas precisar até que esteja satisfeito com o resultado. Abra seu banco de dados .4db, realize algumas mudanças, depois convertá-o de novo e teste o resultados. Cada nova conversão substitui a anterior.

Lembre que uma exportação é uma operação unidirecional:

• Quando tiver exportado um banco de dados 4D como projeto, ambas as versões se tornam independentes.
• Um projeto não pode ser exportado a um arquivo .4db   
• Como os projetos dependem da maioria das tecnologias modernas, não são compatíveis com algumas funcionalidades herdadas. Estas funcionalidades são atualizadas automaticamente se for possível, ou geram erros de conversão (ver abaixo).

4D Server: por padrão, a estrutura dos projetos interpretados abertos por 4D Server e aos que se acessa com 4D em modo remoto é de apenas leitura (não podem ser modificados métodos, formulários, etc). Como se explica nesta página, o desenvolvimento multiusuário com projetos deve basear-se nas ferramentas padrão de controle de fontes. Entretanto, se costumava trabalhar em equipe com 4D remoto em bancos de dados binários, como primeiro passo para uma migração completa, pode considerar usar o modo desenvolvimento (ver Ativar modo development).

Quando converter um banco de dados 4D já existe a um projeto, o arquivo .4db é deixado intacto: uma pasta chamada "Project" é criada do lado de seu arquivo .4db e vai conter todos os arquivos necessários.

Nota: se uma pasta chamda "Projeto" já existir no mesmo nível que seu arquivo .4db (por exemplo se já tiver feito uma conversão), será substituido pelo processo de conversão. 

Para converter um banco de dados a um projeto:

1. Abra o banco de dados a converter.
2. Selecione File > Export > Structure to project.  
   

Notas:

• Este item de menu só está disponível em 4D monousuário.
• Este comando só está disponível se o banco de dados binário estiver aberto - está desativado em bancos de dados projeto
• Também pode usar o comando Export structure file.

Se a conversão tiver sucesso e nenhum erro for encontrado, a caixa de diálogo abaixo é exibida:

• Revelar histórico: ressalta o arquivo de histórico de conversão no seu disco. Ler este arquivo é altamente recomendável porque o processo de conversão pode ter modificado partes da aplicação (ver a seção abaixo Verificando a conversão).
• Abrir Projeto: reinicia a aplicação 4D e carrega o projeto convertido.

O arquivo de dados é deixado intacto pela conversão. Apenas elementos de desenvolvimento são convertidos. Ainda pode abrir seu arquivo de dados com o arquivo de estrutura .4db depois da conversão.

Além disso, as pastas Resources, Logs ou Web de .4db são usadas automaticamente pelo projeto sem modificações. Isso faz com que conversão e testes de projeto sejam mais fáceis.

Durante a conversão, uma nova pasta "Projeto" é criada no mesmo nível que seu arquivo de estrutura .4db. Contém todo o desenvolvimento de sua aplicação como arquivos de texto: formulários, estrutura, métodos, triggers, menus, dicas, listas. Também contém um arquivo .4DProject que é seu arquivo principal de projeto 4D convertido:

Quando abrir seu arquivo .4DProject com sua aplicação 4D, o projeto usa a mesma pasta recursos e web como existentes no arquivo .4db, o que faz que seja mais fácil testar seu projeto.

Também pdoe abrir seu banco de dados .4db, realizar modificações se exigido (ver abaixo), então exportá-los de novo, e testá-los. Pode repetir esta operação até que esteja satisfeito com a conversão.

Um arquivo de histórico em formato JSON é criado por padrão durante o processo de conversão para referenciar todos os problemas que exijam uma ação do conversor. Neste arquivo são classificados em três categorias (propriedade "seriedade/severity") por exemplo:

• info: descreve uma ação necessária executada automaticamente pelo conversor que não terá impacto na interface ou propriedade de aplicação. Por exemplo, se tiver imagens na biblioteca de imagens, 4D exporta-as para a pasta Resources da pasta do banco de dados (ver exemplo acima).

• Aviso: descreve uma ação necessária executada automaticamente pelo conversro que poderia levar à diferenças nas propriedades ou interface da aplicação, mas sem impedir que rode o banco de dados. Avisos geralmente exigem que controle seu impacto sobre a conversão do código. Por exemplo, avisos são retornados quando configurações não compatíveis como "modo Unicode" ou "Botões de seleção agrupados por nome" são mudadas automaticamente. 

• erro: descreve um problema que exige sua intervenção para ser corrigido. Pode impedir que o banco de dados rode corretamente. Por exemplo, alguns objetos de formulário obsoletos não são mais comaptíveis, como botões de highlight. Neste caso, deve converter o botão por si mesmo para um botão 3D no arquivo .4db antes de reexecutar a operação de conversão. 

Quando edições são exigidas no banco de dados .4db, basta modificar o código ou o formulário de forma corresponde e exportar a estrutura de novo. Repita tantas vezes quanto necessário até que esteja satisfeito com o resultado

Durante a conversão, algumas tecnologias 4D já obsoletas são convertidas para implementações mais modernas, e outras são modificadas ou descartadas. Especialmente:

• A biblioteca de imagem não existe mais em projetos. Durante conversão, 4D exporta todas as imagens à pasta Resources do banco de dados.
• Objetos formulários e propriedades de objeto formulários foram atualizados (agora usam a mesma grama´tica que Formulários Dinâmicos ). Partes obsoletas não são compatíveis
• As subtabelas (obsoletas desde 4D v11, ver Sub tabelas) não são compatíveis com projetos.
• Grupos aninhados em objetos formulários não são compatíveis com projetos (grupos são implementados apenas ao nível de objetos). Durante a conversão, grupos aninhados são extraídos até o nível mais baixo
• A propriedade Tabable não é compatível com projetos porque a ordem de entrada é gerenciada pela coleção entryOrder em Formulários Dinâmicos . Durante a conversão, a coleção é automaticamente preenchida com respeito à configuração de ordem de entrada existente (propriedades layering de objeto e tabable). Deve verificar no banco de dados projeto que a ordem de entrada do formulário esteja convertida corretamente.
• Configurações compatibilidade são todas resetadas para um novo banco de dados. Veja o arquivo de histórico Conversão para verificar o estado das configurações de compatibilidade para seu banco de dados.
• Opções compatibilidade formulário (por exemplo. "Dynamic adjustment","With Constraints") são todas resetadas para um novo formulário.
• Folhas de estilo são exportadas como folhas de estilo CSS em arquivos JSOn armazenados na pasta "/SOURCES" chamada:
  • "styleSheets_mac.css" para macOS,
  • "styleSheets_windows.css" para Windows.
    Folhas de estilo aplicadas são adicionadas como atributos "class" para descrições de objetos formulário JSON.
• Objetos formulários automaticamente expandem para baixo quando o CSS ou tamanho fonte plataforma for muito grande. Isso previne o texto de ser truncado
• Comentários Explorer são exportados como arquivos de documentação do tipo markdown (texto simples). Veja developer.4d.com para mais informação em arquivos de documentação markdown.

Os objetos e propriedades de formulário abaixo não cumprem com os requisitos atuais da interface e estão em desuso. Não são compatíveis com Formulários Dinâmicos , e geram um aviso ou erro no arquivo de registro de conversão de projeto (ver comentários).

Por causa de mudanças de comportamento em projetos, a renderização de objetos de formulário pode ser diferente quando se utilizam comandos de formato com parâmetros predeterminados ou faltantes.

As opções de estrutura de banco de dados estão obsoletas e podem gerar erros no arquivo de histórico de conversão de projeto (ver comentários).  

Os editores e funcionalidades de Caixa de ferramentas abaixo estão em desuso não são compatíveis com projetos:

Durante conversão, usuários e grupos 4D existentes são extraídos automaticamente do arquivo .4db e armazenados no arquivo directory.json para o projeto. 

Em projetos, já que o código é armazenado em arquivos de texto de formato aberto, o gerenciamento de acesso de usuários 4D funciona diferentemente que em bancos de dados binários. Em particular:

• em modo monousuário, o sistema de senhas está sempre desativado:
  • a caixa de diálogo login nunca é mostrada, 
  • o usuário atual é sempre Designer,
  • as configurações para servidor SQL ou servidor Web são ignoradas (mas podem ser estabelecidas para lançamento cliente/servidor).
• não há diferença entre usuários criados pelo Designer ou pelo Administrador. 
• não é possível atribuir grupos de acesso ou grupos proprietários aos menus, métodos e formulários. Proteção de código deve ser manejada ao nível de ferramenta de controle de source
• IDs de usuários e grupos (referências) são gerenciadas dinamicamente durante a sessão, entretanto não são armazenadas.

Nota: em modo cliente-servidor, o controle de acesso de usuário funciona em bancos de dados projetos como um banco de dados binários. Entretanto, atribuição de grupos a menus, métodos e formulários não é compatível (ver nota de segurança).

Por isso, depois da conversão:

• Usuário "Desenvolvedor" não existe mais, todos os usuários (com exceção de Designer e Administrador) são apenas do tipo "Usuário". 
• Tipo Grupo e proprietário Grupo foram removidos.
• IDs de usuários estáticos e grupos não são mantidos, exceto para o Designer (ID=1) e o Administrador (ID=2).
• No histórico de banco de dados, a informação  "user4D_id" é substituída por "user4D_alias" que é o alias/apelido do usuário 4D (nome de usuário 4D se nenhum alias for estabelecido).

Nota de segurança: Já que bancos de dados projetos não são compatíveis com atribuição de grupos a métodos (assim como a menus e formulários), não permitem controlar fórmulas 4DACTION/ urls ou 4D Write Pro/4D View Pro através do acesso usuário 4D. Se seu banco de dados usava este tipo de controle, precisa implementar propriedades de segurança de baixo nível como  o atributo “Available através das etiquetas 4D HTML e atributo URLS (4DACTION...)” para métodos e fórmulas SET ALLOWED METHODS. 

Quando construir um projeto aplicação cliente-servidor que controle o acesso através de usuários e grupos, tenha certeza de copiar o arquivo directory.json na pasta Settings da pasta de dados para que esteja aidsponível na aplicação servidor resultante. 

Bibliotecas de objetos personalizados já existentes (.4il em Windows ou .4dlibrary em macOS) devem ser exportadas separadamente se quisesr usá-las em seus projetos. Para saber mais veja este blog post.  

A estratégia de lançamento de projetos 4D se baseia em arquivos.empacotados 4dz, onde toda a estrutura é de só leitura. Este é o caso das aplicações fusionadas, ou dos componentes compilados. Em consequência, os comandos que modificam a estrutura não funcionarão e não devem ser utilizados nas aplicações lançadas. Se forem chamadas, não farão nada ou lançarão um erro, dependendo do contexto.

Lembre que não é recomendado modificar os arquivos de estrutura nas aplicações lançadas pelas razões abaixo:

• impede a instalação de aplicações fusionadas em pastas de Aplicações padrão, nas quais os usuários às vezes não têm direitos de escrita
• rompe a assinatura das aplicações assinadas, em cujo caso o SO pode considerar que foram infectadas
• faz com que a atualização das versões da estrutura lançada seja muito complexa quando tiver que salvar as modificações locais.

Entretanto, se for absolutamente necessário evitar o formato  .4dz e manter a pasta "Projeto" tal qual, para poder modificar seus arquivos fonte nos sites lançados (o qual não é recomendável, como se explicou anteriormente), pode ser interessante a chave PackProject . 

Aquí está a lista de comandos que modificam a estrutura:

Quando um banco de dados é convertido para um projeto, o backup archive counter é resetado. Isso significa que o primeiro arquivo de backup em um projeto convertido vai se chamar myBase-0001, não importando o número de sequência do último arquivo no banco de dados binário.

O contador de arquivo de backup está linkado ao arquivo estrutura do banco de dados. Se renomear ou mover um arquivo  4DB file, e principalmente se o converter para um .4DProject, um novo contador backup recomeça.

Quando estiver satisfeito com seu banco de dados convertido e quiser começar a trabalhar em seu projeto, pode limpar seu diretório de trabalho:

1. Remova seus arquivos .4db e .4dindy da pasta de aplitação (ou seja, mova os arquivos para um diretório backup). Em macOS, pode precisar usar anteriormente o comando Show package, ou remover a extensão .4dbase (ver abaixo). 
2. Em macOS, remova a extensão de pasta .4dbase durante toda a fase de desenvolvimento. Já que vai trabalhar com arquivos de texto e colocá-los em uma ferramenta de controle de source, vai precisar ter acesso direto aos arquivos. 

Se quiser o arquivo de dados a ser aberto automaticamente depois do projeto ser movido para outras máquinas, pode fazer com que seja compatível com a arquitetura de projeto como descrito em developer.4d.com:

1. Mude o nome de seu arquivo de dados  "data.4dd".
2. Crie uma pasta chamada "Data" e mova o arquivo data.4dd para dentro desta pasta
3. Armazene a pasta Data no mesmo nível que a pasta Project.