/*Respostas da sessão de Perguntas e Respostas – Livestream sobre o Technology Stack*/

Ir para respostas em inglês     Ir para respostas em alemão

Linguagem e Framework

• As tabelas alias continuarão funcionando da mesma maneira?
  O conceito de tabelas alias continua sendo possível. Atualmente, isso funcionaria simplesmente instanciando outro DataDictionary da mesma entidade com um nome de objeto diferente.
   
• Os conceitos de ‘global file buffer’ e ‘local buffer’ vão se tornar coisa do passado com a Fase 2 do Technology Stack?
  O global file buffer será removido nas primeiras versões do tech stack. Ao converter código que depende desse buffer, pode-se usar uma instância singleton global da estrutura de DDO como substituto, já que as APIs globais do banco de dados serão redirecionadas para instâncias de Data Dictionary.
   
• Com o redesenho dos tipos de dados, haverá suporte nativo para Null?
  Atualmente, estamos realizando experimentos com suporte a Null em membros de Struct.
   
• Quanto terei que adaptar meu código existente para que funcione com o novo runtime?
  A linguagem é bastante compatível, com a remoção de algumas técnicas muito obsoletas. No entanto, algumas classes foram modificadas — como a nova cHttpClient, que substitui as classes cHttpTransfer. Além disso, o framework de interface do Windows não será incluído inicialmente, pois o foco está no Web e Flextron. Por outro lado, todo o código de UI Web deve ser altamente compatível, pois continuamos usando o mesmo Web App Framework de sempre.
   
• Ainda poderemos usar símbolos no formato nomedatabela.nomecoluna ao referenciar uma coluna no código?
  Sim, todas as APIs globais de banco de dados foram redirecionadas para os DataDictionaries. Isso significa que, ao substituir o nome da tabela por um DD correspondente, o funcionamento será mantido. Para compatibilidade retroativa, basta criar um objeto com o mesmo nome da tabela, e isso deve resolver (na forma como visualizamos atualmente).
   
• Qual será o substituto para as propriedades data_file e data_field?
  Tudo que sugira como o código acessa o banco de dados é interessante. Elas ainda têm utilidade, já que Data_File agora é substituído por um handle para o objeto DataDictionary. Assim, o código existente que as utiliza deve continuar funcionando.
   
• Não haverá mais o file list. Como as alterações serão gerenciadas?
  O Studio continuará com o editor de tabelas e outras ferramentas que você já conhece. No entanto, agora também será possível fazer alterações diretamente no código.
   
• O runtime no lado cliente permitirá o uso de teclas de função novamente?
  O Client Web Application Framework já suporta teclas de função por meio de Key Handlers, e isso continuará funcionando.
   
• Para esclarecer sobre teclas de função, um cliente web responderá, por exemplo, a F2 = salvar?
  Aplicações Web já respondem a teclas de função como F2. Porém, se o foco não estiver em um controle Web, o navegador pode executar sua ação padrão.
   
• Se um navegador usa, por exemplo, fn + Page Down para rolar a página, ele não pode usá-la como “próximo registro”.
  É possível sobrescrever o comportamento padrão das teclas de função na maioria dos navegadores modernos.
   
• Haverá assistentes para "Criar struct/entidade a partir de tabela do banco de dados", certo?
  Já temos ferramentas internas que convertem definições de tabelas DataFlex via Studio em arquivos de definição de entidade. Assistentes são o próximo passo.
   
• Ao definir tabelas como structs, também é possível especificar índices?
  Na versão interna atual, você fornece colunas, atributos, índices e os relacionamentos entre as entidades.
   
• Como seria a sintaxe dentro de um Procedure Creating ou Update, por exemplo, na definição de uma classe DD? Digamos que você queira atualizar uma tabela pai, mas não sabe o nome do objeto DD.
  Já é possível fazer isso usando métodos que identificam a tabela responsável. Você os encontra na documentação do stack atual. Dependendo do caso de uso, ainda estamos ajustando alguns detalhes. Esperamos que, no futuro, a abordagem seja apreciada — se não totalmente compatível, ao menos prática.
   
• Os métodos e propriedades da nova classe de transferência HTTP (cHttpClient) funcionarão da mesma forma ou será necessário adaptar muito?
  Haverá algumas mudanças, mas a API será familiar e foi projetada para durar pelos próximos 20+ anos. E agora você também poderá utilizá-la em todas as plataformas (WebAssembly, Windows, etc.).

Studio

• E o Studio — ele será baseado na web ou continuará sendo exclusivo para Windows?
  O TechStack utilizará o Studio atual, que continuará sendo uma aplicação Windows por enquanto. A visão de longo prazo é ter um Studio baseado em tecnologias web.
   
• O Studio funcionará no Linux e macOS no futuro?
  Esse é o objetivo de longo prazo. Inicialmente, as aplicações rodarão via WebAssembly e, mais adiante, também de forma nativa no Linux e macOS. Quanto ao Studio em si, estamos avançando gradualmente rumo a uma versão baseada na web. Isso significaria que ele poderia rodar como uma aplicação FlexTron no Windows, macOS ou Linux — ou até mesmo na nuvem. Ainda não há um cronograma definido, mas todas as decisões que tomamos hoje seguem essa direção. Por enquanto, o Technology Stack continuará utilizando o Studio atual.
   
• O DataFlex terá suporte para outros editores como o Visual Studio Code?
  Estamos explorando ativamente essa possibilidade. Não planejamos substituir o Studio atual, mas queremos ser mais abertos a ferramentas externas. Por exemplo, atualmente temos um estagiário trabalhando em um language server (LSP) para DataFlex. LSPs são o que tornam possíveis recursos como o IntelliSense em editores como o VS Code. Isso permitiria que outras ferramentas e editores tivessem melhor suporte ao DataFlex. A longo prazo, isso também abre espaço para substituir o editor do Studio por algo mais moderno, como o Monaco — o editor usado no VS Code.

Dados

• O que acontece se você compilar o modelo de banco de dados dentro da aplicação e depois executá-la em diferentes empresas com tamanhos de campos diferentes?
  Certamente haverá flexibilidade no sistema para lidar com esse tipo de situação.
   
• O DataFlex virá com um banco de dados padrão ou um banco gratuito recomendado para substituir o banco de dados embarcado atual, especialmente para novos programadores?
  Atualmente, nossa intenção é substituí-lo pelo SQLite, para oferecer tanto a simplicidade de um banco de dados em arquivo único quanto o poder do SQL.
   
• Como vocês imaginam a conexão de dados entre o cliente e o servidor?
  Essa conexão será totalmente opcional — com suporte offline e tudo. Você poderá se conectar manualmente usando o cHttpClient ou utilizando os HttpDatabaseDrivers que vamos fornecer, ideais para trabalhar com Data Binding e Data Dictionaries.
   
• Dicas sobre como implantar rapidamente novas atualizações (e alterações no banco de dados) de forma transparente para clientes On-Premise?
  Ainda não finalizamos completamente o design do processo de reestruturação de tabelas de banco de dados, mas isso está sendo levado em consideração no planejamento.
   
• A API do Data Dictionary é bastante verbosa. Como isso será tratado?
  Os Data Dictionaries foram completamente reescritos em código DataFlex, o que permite depurá-los com mais facilidade e entender melhor o que está acontecendo. Também vamos refatorá-los e fornecer camadas adicionais de compatibilidade retroativa para quem precisar.

 FlexTron e Windows

• Como será o modelo de uma aplicação FlexTron?
  Presumivelmente, ela ainda exigirá o cliente DataFlex para executar o .exe, mas o novo runtime será executado dentro dos control hosts locais. Embora seja possível rodá-lo de outra forma, isso apenas geraria custos adicionais. Portanto, o novo runtime continuará rodando nativamente no Windows, como acontece atualmente, utilizando o paradigma FlexTron existente, com apenas o framework JS da Web App.
   
• Por quanto tempo as aplicações desktop nativas do Windows serão suportadas?
  O runtime do Technology Stack não oferecerá suporte a aplicações desktop nativas do Windows nas primeiras versões. E mesmo quando passar a oferecer, converter grandes aplicações existentes para a nova stack será um investimento que nem todos os clientes poderão fazer. Por isso, pretendemos manter o runtime clássico por bastante tempo, o que significa que continuaremos lançando atualizações para corrigir erros e adicionar recursos por um bom tempo.

Cronograma

• Qual é a previsão de lançamento para o Technology Stack?
  Esperamos trabalhar o mais rápido possível em direção a um Technical Preview, semelhante aos ciclos de desenvolvimento que vimos durante a criação do DataFlex 20.0.
   
• Quando podemos esperar as primeiras versões em formato de imagem Docker?
  Isso está previsto para a Fase 2, quando criaremos um novo Web App Server que não dependerá mais do Internet Information Server e poderá rodar em outras plataformas além do Windows. Nessa fase, será possível baixar uma imagem publicada do webappserver.

Outros

• A DataFlex está trabalhando com IA?
  Sim, estamos experimentando o uso de IA para recursos como autocompletar código. Pense nisso como um copiloto prático para desenvolvedores. Ainda está em fase inicial, mas estamos explorando como a IA pode apoiar e melhorar a experiência de desenvolvimento.
   
• Por que usamos chave primária numérica e não UUID diretamente?
  A maioria dos sistemas de banco de dados oferece autonumeração, e pretendemos usar a autonumeração do banco sempre que possível. Quando o banco de dados oferecer suporte a UUID, também pretendemos dar suporte a isso. A escolha entre UUID e chaves numéricas também é, em parte, uma questão de preferência.
   
• Como isso será seguro? Como o servidor saberá que é realmente a aplicação DataFlex?
  A segurança continuará como no desenvolvimento web padrão em qualquer linguagem: você ainda precisará implementar autenticação, verificação de tokens de sessão, etc.
   
• A DataFlex permitirá autenticação do Windows em WebApps, para que os usuários possam usar suas credenciais do Windows?
  Já existem maneiras de fazer isso. Uma delas é no nível do IIS, onde você pode configurá-lo para autenticar, e então, no DataFlex, verificar os cabeçalhos HTTP no Session Manager para saber qual usuário está conectado. Além disso, estamos trabalhando em uma biblioteca de Single Sign-On com suporte ao IntraID para integração com Azure Cloud.
   
• Qual será a política de licenciamento para o novo runtime, como imagens Docker e WebAssembly?
  Atualmente, não temos uma resposta definida para isso. No entanto, é de se esperar que o licenciamento para implantações do WebApp Server siga um esquema semelhante ao atual.
   
• Você mencionou que não é possível contar usuários em JavaScript. Isso será possível com WebAssembly?
  Não, pois ambos rodam no cliente e, assim como no desenvolvimento web, o cliente nunca pode ser considerado totalmente seguro ou à prova de manipulação.
   
• Por que não existe um arquivo de workspace?
  No ambiente WebAssembly, não queremos depender de muitos arquivos externos em tempo de execução. Portanto, nesse ambiente, não esperamos usar (ou precisar) de um arquivo de workspace. Em outras plataformas (nativas), o arquivo de workspace pode voltar se houver necessidade.
   
• A mudança dos EUA para a Europa está por trás dessa mudança?
  Não diretamente. Isso poderia ter acontecido nos EUA também. Nossa equipe de P&D europeia já estava envolvida no desenvolvimento do DataFlex e conseguiu atrair novos talentos, o que nos deu a oportunidade de realizar projetos como este.
   
• Os testes unitários farão parte do pacote oficial do DataFlex ou continuarão sendo uma biblioteca complementar?
  Atualmente, é uma biblioteca complementar que você pode encontrar aqui.
   
• E quanto à integração com GitHub e Git?
  A integração com Git no Studio é um pedido popular: a capacidade de trabalhar com repositórios, ver alterações e fazer commits diretamente. Está definitivamente na nossa lista de desejos, mas não é algo que esteja em desenvolvimento ativo no momento. O que estamos fazendo ativamente é melhorar a integração do DataFlex com o GitHub. Queremos que ele seja reconhecido como uma linguagem, com realce de sintaxe adequado e melhor suporte de busca. Também estamos compartilhando mais código aberto no GitHub para apoiar a comunidade e sermos mais transparentes.