Mudanças em 4D v16

Versões 64-bit de 4D favorecem as novas tecnologias e não são compatíveis com aquelas declaradas obsoletas em versões anteriores de 4D. Para uma lista completa de funções que não são compatíveis com a linha de produtos 4D 64-bit, veja Propriedades específicas de versões 64-bit

A linguagem XSLT transforma os dados XML a qualquer formato (XML, HTML, ou qualquer outro tipo). Os principais navegadores de Internet, assim como o software 4D foi implementado a especificação XSLT 1.0.

Atualmente a tendência XSLT está em declive porque os desenvolvedores consideram que é difícil de usar e de depurar.  Seguindo esta tendência, assim como os comentários dos desenvolvedores, decidimos que a funcionalidade de transformação XSL não será desenvolvida para versões 4D de 64 bits.

No entanto, para suportar a nossos clientes que continuam utilizando XSLT em 4D, escolhemos confiar na livraria XSL PHP, que oferece uma completa API que lhe permite realizar todas as operações necessárias para suas transformações XSL. Esta livraria é uma ferramenta eficaz que pode substituir facilmente os comandos _o_XSLT APPLY TRANSFORMATION, [#cmd id="883"/] e _o_XSLT GET ERROR  depois de sua eliminação. 4D produziu um documento específico para lhe ajudar a utilizar PHP XSL como uma substituição para os comandos XSLT de 4D:  Baixe XSLT com o documento técnico PHP (PDF). 

Também lhe sugerimos que considere o uso de etiquetas 4D quando se trata da geração dinâmica de páginas HTML, já que na maioria dos casos é mais fácil gerenciar código HTML como texto sem formato (ver também o comando PROCESS 4D TAGS).

Nota: para visualizar as tendências de pesquisa em XSLT em Google: http://www.google.com/trends/explore#q=xslt    

Por compatibilidade, as transformações XSL continuam suportando em 4D, mas seu uso não se recomenda. O suporte do processamento XSLT será eliminado em futuras versões de 4D.

Nota 4D Server 64 bits OS X: XSLT não está disponível com 4D Server 64 bits para OS X. Portanto, ao chamar um destes comandos desde esta aplicação irá gerar um erro 33 "Comando ou função não implementada".

O formato PICT não será suportado nos próximos grandes lançamentos de 4D e já não deve ser utilizado em 4D.  O comando GET PICTURE FORMATS ajuda a detectar e filtrar o formato PICT em suas imagens. (a função _o_AP Is Picture Deprecated, oferecida através de 4D Pack agora é obsoleta).

Nota: O formato "PICT" Mac foi desaprovado por Apple desde várias versões anteriores de Mac OS (consulte a descrição do formato PICT em Wikipédia).

O formato 'PICT' é um formato bem antigo em Mac. Antes da versão 11, 4D armazenava todas as imagens neste formato, inclusive em Windows. O formato PICT é obsoleto desde que QuickDraw foi declarado obsoleto em 2005.

Há algo importante de entender sobre PICT. Pode armazenar ("encapsular") 2 tipos principais de informação:

• os desenhos em si (seja mapa de bits ou vetorial), ou
• um formato mais moderno (JPEG, por exemplo) armazenado em um PICT utilizando QuickTime. (Geralmente, o desenvolvedor estava chamando _o_QT COMPRESS PICTURE com a constante QT Photo compressor).

Isto significa que inclusive antes quando todas as imagens armazenadas nos arquivos de dados eram PICT, esses PICT podiam, de fato, conter os arquivos JPEG (ou outros formatos). É importante que nossos clientes deixem de usar PICT, não só porque está obsoleto, mas também porque 4D necessita Altura (+ QuickTime utilizou _o_QT COMPRESS PICTURE) para ler PICT em Windows. Isto não é eficiente, e requer que QuickTime esteja instalado.

Ao migrar dados de versões anteriores a v11, os desenvolvedores devem aplicar o comando CONVERT PICTURE para cada campo imagem dos dados. Ao converter os dados das versões mais recentes, se recomenda utilizar o comando  GET PICTURE FORMATS para encontrar imagens que necessitam ser convertidas.

A partir de v16, é possível detectar imagens que usam o formato PICT obsoleto em sua estrutura de banco de dados através de Centro de segurança e manutenção (MSC). Quando usar a propriedade Verificar a aplicação, o arquivo de log proudizdo inclui avisos indicando qualquer imagem encontrada que use ou contenha o formato PICT. Estes avisos podem lidar com imagens estáticas, assim como imagens encontradas na biblioteca de imagens ou objetos formulário.

Nota: Você que deve remover ou substituir imagens que usem o formato PICT obsoleto. Usar o  MSC para realizar uma operação Reparar o arquivo de estrutura não tem nenhum efeito em imagens "obsoletas" e o mesmo aviso vai aparecer no arquivo log.

O suporte para os codecs de imagens relacionados com QuickTime já é obsoleto.

Por padrão, o uso de QuickTime está desabilitado em 4D v14. No entanto, por razões de compatibilidade, pode ser habilitado seu uso utilizando a nova opção de QuickTime support dos comandos SET DATABASE PARAMETER e Get database parameter exceto em versões 64-bit de 4D, no qual QuickTime não é compatível). 

Durante vários anos, o gerenciamento de imagens sob a versão Windows de QuickTime não evoluiu (só a parte de vídeo está evoluindo). Temos a intenção de eliminar o suporte para estas APIs específicas na próxima versão.

4D para Windows de forma nativa suporta todos os principais formatos (JPEG, PNG, GIF, TIFF, etc.), e também suporta WIC (Windows Imaging Component). Se, em seus dados, você tem algumas imagens guardadas em Windows em um formato específico conhecido só por QuickTime, pode ser convertido (CONVERT PICTURE).

Também lhe recordamos que o suporte para os formatos de imagem de QuickTime foi eliminado da versão de 64 bits de 4D Server para Windows como de 4D v12.

Nas versões anteriores de 4D, o servidor web recopiava automaticamente o valor das variáveis enviadas através de um formulário web ou um URL nas variáveis 4D quando tinham o mesmo nome.

Por razões de otimização e controle, este princípio não se mantém a partir de 4D v14: o valor das variáveis Web já não se atribui automaticamente as variáveis 4D. Para recuperar as variáveis enviadas utilizando um POST ou um GET, deve utilizar o comando WEB GET VARIABLES exclusivamente.  Para recuperar as imagens enviadas, deve utilizar os comandos WEB GET BODY PART/WEB Get body part count.

Nota: a atribuição dinâmica também está desativada por padrão nas bases de dados 4D criadas a partir da versão 13.4.

No entanto, por compatibilidade, este mecanismo se mantém por padrão nas bases de dados criadas com uma versão de 4D anterior a 13.4. Neste caso, pode ser desativado o uso da opção de compatibilidade de atribuição de variável automática na página Compatibilidade das Propriedades da base.

Dado que este mecanismo é obsoleto, se recomenda desmarcar esta opção em suas bases de dados convertidas (e adaptar seu código se for necessário) com o propósito de facilitar futuras evoluções.

O uso de números de identificação QuickDraw para designar fontes é obsoleto e não deve ser utilizado mais. Os comandos_o_Font number e  _o_Font name se conservam em 4D v14 por compatibilidade, mas serão eliminadas em versões posteriores. O comando OBJECT SET FONT agora só aceita nomes de fontes.

Altura Mac2Win se utilizou para levar 4D a Windows. É um conjunto de APIs que ajudaram a levar código Mac OS (pre OS X) a Windows, mediante a tradução das APIs: filesystem, QuickDraw, Resources, PICT, etc. Foi bastante útil e ajudou muito (os desenvolvedores Mac plug-in, por exemplo, poderiam mover seus plug-ins a Windows mais facilmente), mas traduz APIs Mac OS antigas ("obsoleto") e não utiliza a API de Windows nativo moderno: 4D deve eliminar Mac2Win de seu código o máximo possível. Isto é um trabalho longo e difícil e em cada versão de 4D, algumas dependências se eliminam (e substituem por APIs modernas).

Neste momento, 4D ainda depende em parte, ainda mais para poder gerenciar a compatibilidade de antigas bases de dados: Recursos, PICT, parte da gestão dos eventos de usuário, suporte para os plug-ins de terceiros que estão integrados utilizando Altura, etc.

Mediante a eliminação de recursos no arquivo .RSR para separar os arquivos na pasta "Recursos" e mediante a conversão (CONVERT PICTURE) a no-PICT, o desenvolvedor 4D estará pronto uma vez 4D eliminar Altura. Mas as primeiras pessoas preocupadas por este grande passo são os desenvolvedores do plug-in. Eles devem deixar de usar Altura o mais rápido possível, o que significa que têm que reescrever algumas partes de seu código fonte Windows. (Já tinha lhe advertido à muitos anos.

Em várias versões principais, 4D advertiu aos desenvolvedores em contra do uso das sub tabelas. Desde 4D v11, é impossível criar um campo do tipo sub tabela. Os sub registros têm algumas limitações conhecidas. Por exemplo, sempre se carregam em memória; não se gerenciam pelos comandos SEND RECORD ou DUPLICATE RECORD.

Não temos planos de eliminar o suporte para as sub tabelas em um futuro próximo, mas é realmente o momento de que os desenvolvedores convertam suas sub tabelas a tabelas N-> regulares porque temos a intenção de eliminar em uma futura versão principal de 4D. Os desenvolvedores que utilizam sub tabelas por razões de rendimento (algumas situações específicas nas que a carga dos registros relacionados era lenta) fiquem tranquilos, especialmente com v12: utilizar as relações N <-> 1 clássicas é bem rápido.

Basicamente, há duas formas principais para eliminar sub tabelas (nota: o seguinte não é uma tecnologia completa de ponta; só uma visão geral rápida):

• Antes da conversão de uma estrutura pre-v11: em 2004, criar a tabela N apropriada e o campo ID na tabela 1 (se não já está ali). Logo, mude o código em todas as partes se for necessário (ver mais a frente).
• Depois da conversão: nesta situação, 4D substitui a sub tabela com uma tabela N usando uma relação especial, que permite que a linguagem para trabalhar com a sub seleção e os sub registros. O desenvolvedor 4D necessita eliminar esta relação especial, substituir ela por uma relação normal e mudar o código por todas partes se for necessário (ver mais a frente).

O que queremos dizer com "mudar o código por todas partes se for necessário" é, basicamente:

• Criar os novos formulários, atualizar os formulários incluídos
• Nos métodos (projeto, formulário, objeto, etc.):
  • Substitua todos os comandos do tema "Sub registros" com o comando Selection ou Record correspondente (por exemplo, substituir CREATE SUBRECORD com CREATE RECORD, enchendo os campos ID)
  • Explicitamente carregar os registros N quando for necessário

Note: a partir de 4D v14 R3, pode atribuir valores aos campos "id_added_by_converter" especiais que se agregam automaticamente por 4D quando converte uma base de dados que contém sub tabelas. Isto lhe permite manter o link "relação sub tabela", e agregar ou modificar registros relacionados, sem necessidade de usar comandos em desuso tais como _o_CREATE SUBRECORD. Uma vez que tenha atualizado seus métodos, estas relações especiais podem ser substituídas por outros estandartes com nenhuma mudança em seu código.

O suporte ao modo ASCII (sinônimo de "modo no Unicode") conduz a um baixo rendimento na manipulação de texto, já que se deve converter desde e para Mac-roman cada vez que se utiliza na estrutura legacy-converted. Planejamos eliminar o modo ASCII em futuras versões principais.

Note que o suporte para o modo ASCII já se retirou para estruturas compiladas que se executem sob 4D Server 64 bits para Windows.

Os desenvolvedores 4D devem, para estruturas convertidas, ativar o modo Unicode. O documento PDF Conversão a 4D v14 da pistas sobre este tema.

Nota para versões 64-bit Também note que o suporte do modo ASCII não está disponível na versão 4D Server 64 bits para OS X.

Esta é outra antiga tecnologia Mac OS, em desuso desde Mac OS X 10.4 (Tiger, 2005). Os recursos se utilizam para armazenar dados estruturados, como texto e cadeias (localização), assim como também ícones, etc. Basicamente, podemos dizer que não são os recursos que estão em desuso, é seu suporte em disco, conhecido como o resource fork. O resource fork é parte do sistema de arquivos de Mac OS e desde o início de Mac OS X, Apple tratou de eliminar este suporte, já que não é compatível com outros sistemas de arquivos (Unix, Windows), e é a fonte de uma grande quantidade de problemas quando os arquivos se transferem através da rede.

Em Windows, este mecanismo se emula e os recursos Mac residem em um arquivo .RSR.

Mas ainda assim, inclusive se há ainda APIs para gerenciar os recursos (e Mac OS gerencia de forma transparente os recursos armazenados em um data fork), já não se recomenda utilizar este velho mecanismo por várias razões:

• Os textos e as cadeias são Mac-roman. Não pode ser armazenado Unicode em recursos de tipo TEXT ou STR #
• Os recursos PICT armazenam PICTs: não é moderno, obsoleto, sem transparência, etc. (Consulte o tema "PICT" acima.)
• A contagem dos recursos e o tamanho dos recursos são limitados (uns 2.700 recursos ou 16 MB)

Eliminamos suporte para comandos de escritura/criação de recursos

A grande maioria das aplicações 4D que utilizam recursos estão, de fato, utilizando recursos "Strings List", 'STR#'. 4D oferece as ferramentas para mudar facilmente do STR # a XLIFF:

• O componente 4D Pop pode criar automaticamente os arquivos XLIFF mediante a leitura e transferir o conteúdo do STR #.
• Todas as rotinas e as expressões que fazem referência a trabalho STR# sem mudança com XLIFF. Por exemplo, Se a etiqueta de um botão ou um menu era ":15000,3" (que significa "conseguir o terceiro elemento de STR# ID 15000"), 4D carregará o XLIFF apropriado (caso exista).

Para outros tipos de recursos:

• Colocar os recursos em arquivos separados dentro da pasta Resources (criar sub diretórios se for necessário):
  • Guardar recursos 'TEXT' em arquivos XLIFF ou .txt
  • Guardar recursos 'PICT' como arquivos .jpg/.png/etc. separado
  • Guardar recursos 'PICT' + MASK’ como arquivos png
  • Utilizar (em Mac) icns em lugar de ICON ou ícones de cores
  • Guardar todos os recursos privados como seja apropriado para você (normalmente: guardar como um arquivo binário com uma extensão específica)
• Utilize a pasta "Recursos" para armazenar seus recursos. Utilize Get 4D folder (pasta de recursos atuais) para obter de forma dinâmica a rota pai para seus recursos.

Há dois tipos de plug-ins: os que utilizam o novo plug-in API e os que seguem utilizando o velho (com QuickDraw). Para os plug-ins que utilizam a velha caixa de ferramentas (com QuickDraw): para manter a compatibilidade, o desenho/renderização já não se realiza diretamente em uma porta QuickDraw, como nas versões anteriores, mas em seu lugar através de uma área GWorld QuickDraw offscreen dedicada ao plugin.

Em consequência, há que respeitar algumas regras, como os plug-ins não devem modificar a porta atual definido pelo recipiente (objeto formulario).

Para os plug-ins que utilizam a nova caixa de ferramentas: só se utiliza esta nova caixa de ferramentas e no QuickDraw: (ver http://sources.4d.com/trac/4d_4dpluginapi/wiki/native_drawing)

Ao longo de diferentes versões, as rotinas mais usadas de 4D Pack foram progressivamente integradas a 4D, enquanto aquelas que iam se tornando obsoletas foram removidas. 4D Pack v16 agora contém apenas um pequeno número de rotinas e não vai mais avançar. A partir de 4D v16, o plug-in 4D Pack como um todo está obsoleto e não será mais oferecido em versões futuras de 4D. Veja a tabela abaixo para encontrar as soluções de substituição disponíveis para as rotinas que ainda permanecem.

O plug-in OLE_Tools  (disponível só em Windows) está obsoleto nas versões 4D 32-bit e não será suportado nas versões 4D 64-bit. Propriedades oferecidas por esse plug-in legado podem ser localizadas, dependendo do caso, pelos comandos Área Web,  LAUNCH EXTERNAL PROCESS ou PHP.

Para maior clareza da linguagem 4D, a partir de  4D v15, cada comando obsoleto tem um prefixo "_o_", se este já não era o caso e não estão mais disponíveis em listas 4D (editor de código, propriedade de type-ahead, etc).

Não serão removidos do código existente  e continuarão a funcionar normalmente enquanto forem compatíveis. Ainda é possível (mas não recomendado) adicionar um comando obsoleto em um método simplesmente digitando seu nome com .o prefixo "_o_" para serem interpretados corretamente.