Links da raiz (dois pontos) e a versão do Viewer.

A partir do E3/Power/Water 6.9, um link iniciado por dois pontos (:) é resolvido da raiz do Domínio. Como é uma mudança de sintaxe, um Viewer de versão anterior não reconhece o : e mostra o link como quebrado.

1. Introdução

A partir do E3/Power/Water 6.9 é possível criar links da raiz — associações cujo caminho começa com dois pontos (:), resolvidas direto da raiz do Domínio em vez de relativas ao objeto que as contém. O recurso evita ambiguidade entre objetos de mesmo nome e melhora o desempenho. Como é uma mudança de sintaxe, um Viewer de versão anterior (ex.: 6.8) não reconhece o : e trata o link como inválido — é o que ocorre ao conectar um Viewer antigo a um servidor já atualizado. Este artigo explica como os links são resolvidos com e sem os dois pontos, por que quebram no Viewer desatualizado e como resolver.

2. Como são os links da raiz (dois pontos)

Um link (associação) normalmente aponta para outro objeto por um caminho relativo ao objeto que contém o link. Prefixar o caminho com dois pontos (:) transforma-o em um link da raiz: o E3 passa a resolvê-lo a partir da raiz do Domínio, ignorando o contexto do objeto de origem.

Dados.Tanque1.Nivelcaminho relativo — resolvido a partir do objeto de origem.
:Dados.Tanque1.Nivelcaminho da raiz — resolvido a partir da raiz do Domínio.

3. Como o E3 resolve um link — com e sem os dois pontos

Sem os dois pontos (relativo — comportamento histórico). O E3 sobe na hierarquia a partir do objeto que contém o link e, no primeiro nível cujo nome casa com o início do caminho, desce para resolver o restante. Se nenhum nível casar, a busca chega à raiz assim mesmo. O risco é a ambiguidade: se existir, em um nível acima, um objeto — ou até uma propriedade do próprio objeto de origem — com o mesmo nome do início do caminho, a resolução “trava” no lugar errado e o link quebra.

Com os dois pontos (forçado da raiz). O comportamento depende do tipo de objeto:

  • Objetos do servidor (Dados, Tags, pastas): o : resolve direto da raiz do Domínio, ignorando o contexto do objeto. Isso elimina os conflitos de nome e ainda acelera a resolução — o ganho é maior quanto mais fundo o objeto estiver na hierarquia.
  • Objetos do Viewer (Telas, Quadros, o próprio Viewer): o : faz o E3 primeiro tentar resolver no próprio Viewer e, se não for um link do Viewer, resolver no servidor sempre a partir da raiz — evitando a busca no contexto da Tela ou do Quadro.

4. Por que o link quebra em um Viewer desatualizado

Os links da raiz são uma mudança de sintaxe sem compatibilidade retroativa. Tradicionalmente, os dois pontos separam o apelido de um Domínio remoto do caminho do objeto (sintaxe Domínio:Caminho). Um : no início do caminho, sem apelido antes, equivale a um nome de Domínio vazio — o Domínio local, mas resolvido da raiz. O interpretador de expressões das versões anteriores não aceita esse Domínio vazio (espera sempre um Domínio remoto ou um alias local) e trata o caminho como link inválido.

Viewer antigo + servidor novo

Uma aplicação que usa os dois pontos exige o Viewer atualizado. Um Viewer 6.8 conectado a um servidor 6.9 exibe os links com : como quebrados em runtime, embora o mesmo projeto funcione normalmente com o Viewer na versão do servidor.

5. Solução: atualize o Viewer para a versão do servidor

Mantenha o Viewer na mesma versão do servidor (6.9 ou superior). Depois de atualizado, os links da raiz passam a ser reconhecidos e resolvidos corretamente. Padronize a versão de todas as estações (servidor e Viewers) antes de publicar links da raiz na aplicação.

6. Benefícios de manter os dois pontos

Com a versão padronizada, vale manter os links da raiz:

  • Fim da ambiguidade entre objetos (ou propriedades) de mesmo nome em níveis diferentes.
  • Desempenho. A resolução direta da raiz é mais rápida, sobretudo em hierarquias profundas e do lado servidor. Em testes internos, forçar os links da raiz reduziu em cerca de 10% o tempo de inicialização de uma aplicação com 100 mil links entre objetos do servidor; em outra medição, o tempo de ativação de um Data Server com 10 mil tags internos em uma árvore de quatro níveis de pastas caiu cerca de 15%.

7. Observações e boas práticas

  • O AppBrowser ajuda a montar a Fonte. Ao criar associações pelo AppBrowser, o caminho normalmente já é gerado como link da raiz (com o :).
  • No E3 Studio, uma Fonte válida aparece em azul; um caminho inválido é sinalizado como erro — útil para identificar um link quebrado já na configuração.
  • Ao digitar a Fonte manualmente, comece o caminho com : para forçar a resolução da raiz. Por script, informe o caminho já com os dois pontos ao criar a associação:
' Associação simples resolvida a partir da raiz do Domínio
Objeto.Links.CreateLink "Value", ":Dados.Tanque1.Nivel", 0
  • Contexto. Antes do recurso, os links de DBServer em Fórmula, Histórico e Storage já eram resolvidos da raiz para evitar conflito com uma propriedade de mesmo nome do próprio objeto. Os dois pontos generalizam esse comportamento para qualquer associação.
Print Friendly, PDF & Email

Este artigo foi útil? Was this helpful?

Classificação média - Average rating 0 / 5. Count: 0

Leave a Reply

Your email address will not be published.Required fields are marked *