Integração de IA
CENTRALIZE FORNECEDORES E MODELOS DE IA COM ALIASES REUTILIZÁVEIS
Os fornecedores e modelos de IA são agora definidos num separador dedicado à IA em Configurações e reutilizados em toda a aplicação.
Cada fornecedor armazena o seu URL base, chave API e identificadores opcionais. As ligações podem ser testadas diretamente, pelo que o acesso é verificado antes de qualquer chamada ser efetuada. Uma vez configurados, os fornecedores passam a fazer parte das definições do projeto e seguem a mesma lógica de implementação nas configurações ao nível da estrutura, do utilizador ou dos dados.
A utilização de modelos é simplificada através de duas abordagens. Pode referenciar modelos utilizando um formato baseado no fornecedor, como ProviderName:ModelName, ou definir aliases de modelos que mapeiam um nome personalizado para um fornecedor e um ID de modelo. Quando o atributo model corresponde a um alias, o 4D resolve automaticamente a configuração do fornecedor e do modelo associados.
Isto elimina a necessidade de repetir detalhes do fornecedor ou identificadores de modelo ao longo do seu código. Mudar de fornecedor, atualizar credenciais ou substituir modelos não requer alterações em vários métodos.
As configurações de fornecedores e modelos permanecem acessíveis em tempo de execução através da classe OpenAIProviders. Pode inspecionar os fornecedores disponíveis, recuperar aliases de modelos ou adaptar o comportamento dinamicamente quando necessário.
A integração de IA torna-se mais fácil de gerir à medida que escala. A configuração permanece centralizada, a utilização do modelo mantém-se consistente e o seu código mantém-se focado na lógica da aplicação em vez de na configuração externa.
Interface do utilizador
VISUALIZAÇÃO LIQUID GLASS PARA FORMULÁRIOS 4D NO macOS
No 4D 21 R3, os formulários no macOS adotam automaticamente o estilo do sistema Liquid Glass.
Objetos padrão, como botões, listas e menus, seguem o espaçamento, a transparência e o feedback visual atualizados definidos pelo macOS. A renderização muda visualmente, enquanto a lógica dos formulários e o tratamento de eventos permanecem inalterados.
Como o estilo introduz transparência e formas arredondadas, os layouts com espaçamento reduzido ou elementos em camadas podem requerer pequenos ajustes.
As aplicações alinham-se com as convenções atuais do macOS sem alterar a forma como os formulários são construídos.
CRIE INTERFACES MODERNAS COM FLUENT UI E LIQUID GLASS
No 4D 21 R3, a Biblioteca de Objetos suporta o Fluent UI no Windows e o Liquid Glass no macOS.
Os componentes existentes são renderizados utilizando o sistema de design selecionado sem alterar a sua definição. Os mesmos formulários adaptam-se em todas as plataformas, mantendo uma interface consistente e moderna sem necessidade de redesenho.
Os componentes atualizados seguem as práticas de desenvolvimento atuais, com métodos de objeto mais simples quando adicionados ou regenerados.
A interface evolui em todas as plataformas, enquanto a estrutura e a lógica permanecem inalteradas.
IMPRIMA FORMULÁRIOS MODERNOS COM RENDERIZAÇÃO OTIMIZADA PARA PAPEL
No 4D 21 R3, os formulários que utilizam estilos de interface do utilizador modernos são automaticamente adaptados para impressão.
Os widgets são convertidos em representações planas e monocromáticas, e os efeitos visuais, como transparência e sombras, são removidos. O layout, o alinhamento e as dimensões são preservados, e os valores impressos correspondem ao estado atual, incluindo dados não guardados.
A transformação é executada automaticamente e produz resultados consistentes no macOS e no Windows, sem alterações na lógica de impressão.
REDE
REDE LEGADA REMOVIDA
No 4D 21 R3, a camada de rede Legacy foi removida.
Os novos projetos utilizam o QUIC por predefinição, enquanto as bases de dados binárias utilizam o ServerNet. A camada de rede é definida no momento da criação com base no tipo de aplicação.
As aplicações existentes que ainda fazem referência ao Legacy permanecem compatíveis. Em tempo de execução, o 4D utiliza o ServerNet, pelo que as aplicações continuam a funcionar numa camada suportada sem necessidade de alterações imediatas.
Os protocolos suportados tornam-se a base, enquanto o Legacy já não faz parte da configuração.
RECEBA EVENTOS DE E-MAIL EM TEMPO REAL COM IMAP IDLE
No 4D 21 R3, o IMAPTransporter suporta o protocolo IDLE, permitindo que as aplicações reajam às alterações na caixa de correio à medida que estas ocorrem.
O comando «IMAP New transporter» aceita agora um objeto «listener», onde podem ser definidas funções de callback para eventos como « onMailCreated », « onMailDeleted » e « onFlagsModified ». Cada callback recebe o «transporter» e um objeto de evento com detalhes como a contagem de mensagens, o número de sequência ou os sinalizadores de atualização.
As notificações são controladas através da propriedade notifier. A chamada de notifier.start() subscreve eventos do servidor, enquanto notifier.stop() os pausa. Quando ativo, o transportador mantém uma ligação ativa e entrega eventos em vez de depender de sondagens periódicas.
Isto muda o tratamento do e-mail de verificações agendadas para um fluxo orientado por eventos. As aplicações mantêm-se alinhadas com o estado da caixa de correio, reduzem pedidos desnecessários e podem atualizar a interface do utilizador ou acionar a lógica assim que ocorrem alterações.
4D Write Pro
ESTRUTURE DOCUMENTOS COM LISTAS NUMERADAS HIERÁRQUICAS
No 4D 21 R3, as listas numeradas no 4D Write Pro passam de uma simples formatação para uma organização estruturada de documentos. Agora pode definir uma numeração hierárquica em vários níveis, permitindo que secções, subsecções e conteúdo aninhado se mantenham consistentes automaticamente.
A numeração é definida através de estilos de parágrafo ligados, em que cada nível segue uma hierarquia estruturada. Formatos como 1, 1.1 e 1.1.1 são gerados automaticamente.
Quando o conteúdo é adicionado, removido ou reorganizado, a numeração atualiza-se em todos os níveis sem necessidade de ajuste manual.
Esta abordagem elimina a necessidade de reiniciar a numeração ou de a manter através de código. Em vez disso, a numeração segue a estrutura que definir, garantindo a consistência em documentos longos ou complexos.
Linguagem 4D
Aceda às sessões de utilizador diretamente a partir do 4D CLIENT
No 4D 21 R3, o comando Session foi alargado ao 4D Client e agora devolve o objeto de sessão remota em vez de Null.
Os dados da sessão, tais como o ID da sessão, o nome de utilizador e o contexto, tornam-se diretamente acessíveis a partir do 4D Client. Funções como createOTP(), getPrivileges(), hasPrivilege() e isGuest()podem ser chamadas localmente, continuando a refletir a sessão do servidor.
Isto elimina a necessidade de reorganizar o código apenas para aceder às informações da sessão. A lógica pode permanecer onde é utilizada, o que torna os fluxos mais fáceis de acompanhar e reduz o número de métodos intermédios necessários nas aplicações cliente-servidor.
Os cenários híbridos também se tornam mais diretos. Um cliente pode gerar um OTP e abrir uma página Qodly dentro do mesmo contexto autenticado sem coordenação adicional.
As restrições do lado do servidor permanecem inalteradas. As funções de modificação de privilégios continuam a ser executadas apenas no servidor, e o armazenamento do cliente permanece separado.
O tratamento de sessões torna-se mais fácil de integrar no código existente sem o reestruturar em torno do contexto de execução.
EXECUTAR FUNÇÕES SINGLETON PARTILHADAS E DE SESSÃO NO SERVIDOR
No 4D 21 R3, as funções de singletons partilhados e de sessão suportam a palavra-chave ` server `, permitindo que sejam executadas no servidor mesmo quando chamadas a partir de um 4D Client.
A função é executada na instância do lado do servidor do singleton. Se não existir nenhuma instância, esta é criada automaticamente, o que significa que um singleton pode existir tanto no cliente como no servidor com valores de propriedade distintos.
Isto aplica-se a classes de singletons partilhados e de sessão. A palavra-chave « local » pode continuar a ser utilizada para maior clareza, enquanto as funções do modelo de dados ORDA também aceitam « server » para maior explicitação.
Os parâmetros e valores devolvidos devem ser transmissíveis, seguindo o mesmo modelo de execução das funções ORDA do lado do servidor.
A lógica relacionada com a sessão, as operações de memória partilhada e o processamento dependente do servidor podem agora permanecer dentro do singleton que os define, sem serem movidos para métodos do projeto ou funções ORDA para controlar o local de execução.
Transforme texto dinâmico em métodos executáveis reais
No 4D 21 R3, a nova classe ` 4D.Method ` permite que o código armazenado como texto seja executado como um método nativo.
Um método é criado utilizando 4D.Method.new() e comporta-se como um método nativo. Pode ser executado, armazenado em objetos ou invocado utilizando call() e apply(). Os parâmetros são passados de forma estruturada e This devolve o objeto anfitrião durante a execução.
Antes da execução, checkSyntax() valida o código-fonte e devolve informações detalhadas sobre erros e avisos, incluindo números de linha.
Isto permite introduzir lógica dinâmica sem sacrificar o controlo. O código armazenado em bases de dados ou fontes externas pode ser validado e executado utilizando o mesmo modelo de linguagem, o que torna a personalização em tempo de execução mais fiável e fácil de manter.
A execução permanece consistente em todos os ambientes, uma vez que os métodos são executados em modo interpretado, mesmo em aplicações compiladas.
O comportamento dinâmico integra-se na aplicação em vez de permanecer como um mecanismo isolado.
VALIDAR JSON COM PADRÕES DE ESQUEMA MODERNOS
No 4D 21 R3, o comando ` JSON Validate ` suporta agora o mais recente padrão JSON Schema (Rascunho 2020-12).
Os esquemas podem agora incluir lógica condicional, restrições avançadas e validação de formato alargada. Isto permite que mais regras de validação sejam expressas diretamente no esquema, em vez de serem implementadas no código.
Como resultado, a lógica de validação pode ser partilhada entre sistemas sem duplicação. Os serviços de backend, frontend e externos podem basear-se no mesmo esquema, o que mantém o comportamento alinhado à medida que os dados fluem entre eles.
A comunicação de erros é mais precisa, tornando os problemas de validação mais fáceis de identificar e corrigir. Os esquemas Draft-04 existentes continuam a ser suportados, e o motor de validação é selecionado automaticamente com base no atributo ` $schema `.
VALIDAR DATAS DE FORMA CONSISTENTE EM ESQUEMAS JSON
No 4D 21 R3, o JSON Validate trata as datas de forma consistente, quer estejam armazenadas como cadeias de caracteres ou como valores 4D Date nativos.
A validação segue a definição do esquema, independentemente da forma como a data é representada internamente. Isto elimina inconsistências quando os dados circulam entre JSON, APIs e o processamento interno.
Os esquemas continuam a ser a referência para as regras de validação, sem necessidade de lógica de conversão adicional antes da validação.
DETECTE ERROS DE PARÂMETROS DE COMANDOS MAIS CEDO NO EDITOR
No 4D 21 R3, a verificação de sintaxe foi alargada para validar parâmetros de comando diretamente no editor, utilizando os tipos e padrões de sintaxe definidos na documentação.
Quando um comando espera um tipo específico, como Texto, Inteiro, Objeto, Ponteiro ou uma variável atribuível, os argumentos inválidos são agora detetados durante a escrita do código, em vez de surgirem mais tarde em tempo de execução ou durante a verificação de sintaxe. Isto também se aplica a parâmetros multitipo documentados, parâmetros variádicos e grupos de parâmetros variádicos.
As verificações são agora mais precisas para casos comuns, tais como tipos de argumentos errados, valores não atribuíveis passados onde é necessária uma variável, ou assinaturas de comandos que dependem de uma sintaxe específica documentada. A verificação de sintaxe de comandos existente não é substituída aqui. É alargada para abranger um conjunto mais vasto e mais exato de regras de parâmetros, tanto no editor de código 4D como no VS Code.
Isto aproxima a utilização dos comandos do que a documentação define efetivamente, pelo que as chamadas inválidas são identificadas mais cedo e corrigidas antes de se propagarem mais para o ciclo de desenvolvimento.
Componente 4D
GERIR AS DEPENDÊNCIAS DOS COMPONENTES DO GITLAB A PARTIR DA INTERFACE DO PROJETO
No 4D 21 R3, a interface de Dependências do Projeto suporta agora repositórios GitLab, alargando a gestão de dependências existente para além do GitHub.
Os componentes podem ser adicionados diretamente a partir de um repositório GitLab utilizando uma URL completa ou um caminho do repositório. Os repositórios privados são suportados através de tokens de acesso pessoais, que podem ser definidos por servidor e reutilizados em todas as dependências.
A seleção da versão segue a mesma lógica que os outros componentes. As dependências podem ter como alvo a versão mais recente disponível, uma tag específica ou uma versão semântica, permitindo um controlo preciso sobre o que é integrado no projeto.
Uma vez adicionados, os componentes do GitLab comportam-se como qualquer outra dependência. São listados na interface de Dependências do Projeto, instalados ao reiniciar o projeto e podem ser atualizados, verificados ou removidos sem sair do ambiente.
A gestão de dependências torna-se consistente entre as fontes do repositório, pelo que os componentes alojados no GitLab seguem o mesmo ciclo de vida e as mesmas regras de versionamento que o resto do projeto.
Extensão do Visual Studio Code
EDITE FUNÇÕES, PRIVILÉGIOS E MANIPULADORES HTTP VISUALMENTE NO VS CODE
Os ficheiros de projeto estruturados podem agora ser editados através de editores de interface do utilizador dedicados diretamente no VS Code.
As funções e os privilégios, bem como os manipuladores HTTP, abrem-se numa interface visual em vez de JSON bruto. Os campos estão organizados, as opções são explícitas e as configurações podem ser atualizadas sem navegar por estruturas aninhadas ou gerir a sintaxe manualmente.
A validação está integrada. É mais difícil introduzir configurações inválidas e os erros comuns causados pela formatação ou estrutura são evitados antes de chegarem ao tempo de execução.
Os mesmos ficheiros permanecem acessíveis como texto a qualquer momento. Pode alternar entre a edição em formato bruto e a interface de utilizador, dependendo da tarefa, sem alterar o seu fluxo de trabalho ou ferramentas.
Isto torna a configuração mais fácil de ler, mais segura de modificar e mais acessível a toda a equipa, mantendo-se totalmente integrada no seu ambiente VS Code.
DEPENDÊNCIAS AGORA TOTALMENTE RECONHECIDAS NO VS CODE
No 4D 21 R3, a extensão 4D-Analyzer carrega as dependências do projeto da mesma forma que o 4D. Com as dependências resolvidas automaticamente, a verificação de sintaxe e a autocompletar de código baseiam-se no mesmo contexto que o IDE do 4D, pelo que o feedback permanece consistente em todos os ambientes.
A extensão lê as dependências tanto do dependencies.json como do environment4d.json. Os componentes partilhados entre vários projetos são detetados sem configuração adicional, e as atualizações destes ficheiros desencadeiam uma recarga automática do projeto, para que as alterações sejam imediatamente refletidas no editor.
A integração com o GitHub segue a mesma lógica do 4D. Os componentes são descarregados utilizando o mesmo armazenamento local, evitando duplicações e mantendo as versões alinhadas. Quando uma sessão do GitHub já está ativa no VS Code, esta é reutilizada automaticamente. Caso contrário, é possível abrir uma sessão diretamente a partir da extensão para aceder a repositórios públicos e privados sem interromper o fluxo de trabalho.
O VS Code deixa de adivinhar. Funciona com as mesmas dependências, a mesma estrutura e as mesmas regras que a sua aplicação 4D
segurança
UTILIZE CERTIFICADOS DO MACOS KEYCHAIN DIRETAMENTE EM PEDIDOS HTTPS
No 4D 21 R3, as solicitações HTTPS e os agentes HTTP podem utilizar certificados armazenados diretamente no Keychain do macOS.
Os certificados são referenciados pelo nome utilizando a propriedade ` storeCertificateName ` ao criar um ` HTTPRequest ` ou um ` HTTPAgent`. O 4D resolve o certificado através do sistema operativo e, se o certificado não for encontrado, é devolvido imediatamente um erro.
Isto segue a mesma abordagem já disponível para o Armazenamento de Certificados do Windows, permitindo que o mesmo código funcione em todas as plataformas.
Os certificados já não precisam de ser distribuídos ou armazenados como ficheiros no ambiente da aplicação. Continuam a ser geridos pelo sistema, o que simplifica a implementação e mantém o tratamento de credenciais consistente entre máquinas.