Criação de formulários em HTML

Quando um design de formulário contém subformulários que se expandem, é difícil saber exatamente quantas páginas serão renderizadas no formulário resultante no tempo de execução. A configuração do tamanho da página é usada para paginar formulários PDF, mas é ignorada quando um formulário HTML é renderizado, pois as páginas HTML podem ter qualquer tamanho.

Para implementar o conceito de um formulário HTML de várias páginas, é possível incluir um subformulário com nível de uma página no seu design de formulário. É necessário um desses subformulários para cada página que você deseja renderizar no formulário. Para formulários contendo elementos flutuantes, cada subformulário que possui conteúdo flutuante deve estar aninhado dentro de um dos subformulários em nível de página. Depois disso, quando o formulário for renderizado, todo conteúdo que pertence ao mesmo subformulário em nível de página será exibido na mesma página HTML.

Por exemplo, considere o design de formulário na seguinte ilustração. O design de formulário inclui três subformulários no nível de página: Subform_Page0, Subform_Page1 e Subform_LastPage. Se o Forms fosse renderizar um formulário HTML com base nesse design de formulário, uma página HTML seria criada automaticamente a partir de cada um dos subformulários de nível de página.

A.

O Subform_Page0 posiciona o conteúdo e é configurado para exibir seus objetos na primeira página do formulário que usa o layout da página mestre Page1.

B.

O Subform_Page1 contém um subformulário com conteúdo flutuante. O Expanding_subform pode repetir a renderização de seus objetos quantas vezes for necessário em resposta aos dados unidos. O conteúdo do Subform_Page1 pode ser exibido em uma ou mais páginas usando o layout da página mestre Page2_etc.

C.

O Subform_LastPage posiciona o conteúdo e foi configurado para exibir seus objetos na última página renderizada usando o layout da página mestre Page3.

Quando o Forms renderiza o formulário HTML no tempo de execução, o subformulário de nível da primeira página é exibido na primeira página. Para a finalidade deste exemplo, a primeira página pode parecer um pouco parecida com a página exibida aqui. Observe o botão Próxima página, que deve ser incluído para que os usuários possam se movimentar para a próxima página do formulário.

Presumindo que pelo menos um registro estaria disponível para unir ao Expanding_subform no tempo de execução, a segunda página pode parecer com o seguinte exemplo de página. Novamente, um botão Próxima página é necessário para que os usuários possam se movimentar para a próxima página do formulário. Além disso, é possível escolher incluir um botão Página anterior no seu próprio formulário.

O subformulário de nível da terceira página, Subform_LastPage, é exibido na última página do formulário renderizado. Neste exemplo, uma mensagem na última página agradece os usuários por preencher o formulário e fornece um botão Enviar para enviar os dados digitados pelo usuário para o Forms.

Para obter informações sobre como gravar um script de forma que os usuários possam se mover entre as páginas HTML, consulte Como gravar um script para manipular páginas HTML.

As seguintes informações o ajudarão a desenvolver formulários HTML com uma boa aparência e fáceis de ler:

• Não use as propriedades de borda de um objeto para desenhar linhas, caixas ou grades no seu formulário. Talvez alguns navegadores não alinhem bordas exatamente como elas aparecem em uma visualização do Designer. Objetos podem aparecer em camadas ou empurrar outros objetos para fora das posições desejadas.

• Se os usuários estiverem usando o Microsoft Internet Explorer, você poderá desenvolver seu formulário com linhas, retângulos e círculos para definir o plano de fundo. Todos os outros navegadores da Web suportam apenas linhas verticais e horizontais; portanto, retângulos e círculos no seu design de formulário não serão exibidos no tempo de execução.

• Se os usuários forem usar navegadores Opera, projete os campos um pouco maiores do que deseja. Os campos no Opera sempre têm uma borda interna em depressão. Quaisquer estilos de borda que você aplicar serão colocados ao redor do lado externo dessa borda. Como a borda em depressão ocupa espaço no campo, a área para preenchimento diminuirá.

• Criar texto estático ligeiramente maior do que o que parece ser necessário para acomodar o texto. O Designer e o Acrobat podem usar kerning diferente do de um navegador da Web específico, e algum texto pode não ser exibido corretamente.

Considere as seguintes diretrizes ao adicionar imagens aos designs de formulário renderizados como HTML.

Arquivos de imagem suportados

É possível incluir qualquer arquivo de imagem (exceto arquivos GIF animados), sujeito às limitações dos navegadores da Web que os usuários precisam para exibir formulários em HTML.

Nota: Tenha em mente que o Internet Explorer processa a combinação dos objetos de botão e imagem de uma forma diferente dos outros navegadores da Web. Por exemplo, se você criar um objeto de botão com uma aparência transparente personalizada e colocá-lo sobre um objeto de imagem, o Internet Explorer pode processar o HTML resultante de forma incorreta, de forma que os usuários não consigam clicar no botão usando um mouse. Consulte Solução para limitações do navegador da Web.

Não incorpore imagens no formulário

O Forms não é compatível com imagens incorporadas. Em vez disso, use nomes de caminho relativos para inserir arquivos de imagem. Por exemplo, o caminho pode ser relativo ao diretório raiz dos formulários do Forms , que, por padrão, é a pasta designada como o repositório dos formulários. A pasta de imagens no seguinte caminho está no mesmo nível que a pasta de formulários:

../images/graphic.jpg

Se você acredita que alguns dos usuários usarão navegadores com recursos limitados, precisa considerar as limitações do menor denominador comum e projetar seus formulários de acordo. Como alternativa, se sua organização usar navegadores que suportam XHTML, terá mais opções para projetar o design de formulário.

Lembre-se das seguintes considerações ao desenvolver formulários que serão vistos em diversos navegadores:

• Especifique um tamanho de página para garantir que a transformação para HTML4 (para Netscape Navigator 4.7.x) exibe todos os objetos estáticos adequadamente. Caso contrário, será reservado espaço suficiente para campos apenas quando o formulário for renderizado.

• Incorpore uma margem de no mínimo 6,35 mm na parte superior e no lado esquerdo do formulário. Qualquer coisa acima e à esquerda dessa margem não ficará visível.

• Objetos ou partes de objetos desenhados em coordenadas de grade negativas não são exibidos. Por exemplo, se você desenhar um objeto começando na coordenada de grade vertical -12, parte do objeto de -12 até a borda interna de uma margem de 6,35 mm não será exibida.

• Deixe espaço suficiente ao redor dos campos para compensar a degradação visual que pode ocorrer em um navegador de baixa definição. Por exemplo, em alguns navegadores, caixas de seleção e botões de opção são exibidos com um tamanho maior do que foram projetados.

• Qualquer alinhamento de dados à esquerda pode não ser mantido quando um navegador de baixa definição for usado para exibir o formulário, especialmente se os usuários alterarem as fontes padrão associadas aos seus navegadores.

• O Internet Explorer processa a combinação dos objetos de botão e imagem de uma forma diferente dos outros navegadores da Web. Por exemplo, se você criar um objeto de botão com uma aparência transparente personalizada e colocá-lo sobre um objeto de imagem, o Internet Explorer pode processar o HTML resultante de forma incorreta, de forma que os usuários não consigam clicar no botão usando um mouse. Entretanto, os usuários ainda podem alcançar o botão com a tabulação e pressionar a tecla Enter ou a barra de espaço. Este erro de processamento ocorre porque o tamanho do objeto de botão depende do tamanho da legenda. A quantidade de espaço vazio na área de legenda precisa ser grande o bastante para que o tamanho do botão seja maior que o tamanho da imagem. Para solucionar este problema, substitua o texto da legenda com espaços vazios suficientes para permitir que os usuários cliquem no botão usando um mouse.

Para testar a operação de seu design de formulário com o Forms e para configurar botões de comando com precisão em um design de formulário, é necessário saber o URL que será associado com solicitações para o Forms. O desenvolvedor do aplicativo personalizado conhece o URL.

Para visualizar um formulário em HTML, é necessário disponibilizar o design de formulário para o Forms de modo que o Forms possa armazenar o design de formulário. Depois disso, é possível solicitar o formulário por meio do URL associado ao Forms. Use um navegador da Web ou um dos aplicativos de destino clientes (como um leitor de tela) para abrir o formulário.

É possível incorporar cálculos e scripts em um design de formulário para executar cálculos, métodos ou operações quando qualquer um dos eventos de um objeto ocorrer em tempo de execução. Por exemplo, um evento ocorre em tempo de execução quando o usuário executa a ação especificada por esse evento. É possível chamar qualquer dos métodos suportados de um objeto e examinar ou definir propriedades por meio da definição de um script.

No Designer, scripts e cálculos são designados, por padrão, para execução no dispositivo cliente. O local de processamento padrão é definido na guia Visualização da caixa de diálogo Propriedades do formulário (selecione Arquivo > Propriedades do formulário). Para suprimir o local de processamento padrão, é possível especificar explicitamente um local de processamento diferente usando a opção Executar em no Editor de scripts quando um script ou um cálculo é anexado a um objeto.

Com o Forms , o processamento pode ser feito no cliente, no servidor ou em ambos. Quando você especificar que um script/cálculo deve ser executado no cliente e no servidor, o cliente e servidor poderão ambos tentar executar o script/cálculo. O Forms sempre tentará processar o script/cálculo se o cliente não puder fazê-lo. Se scripts/cálculos forem designados para execução no servidor, o Forms executará esses scripts e/ou cálculos, reunirá os resultados no formulário e os retornará ao cliente.

Scripts e cálculos de cliente são executados no dispositivo cliente. Ao criar formulários PDF para o Acrobat ou o Adobe Reader, todo o processamento será feito no cliente. Entretanto, se o cliente não conseguir executar o script ou o cálculo, o Forms tentará processá-los.

Para executar um script de cliente em um formulário HTML com êxito, determinadas condições devem ser atendidas:

• O aplicativo cliente deve ser o Microsoft Internet Explorer 5.x, Netscape 6.0 ou mais recente ou o Opera 5 ou mais recente.

• O JavaScript pode ser usado somente para gravar scripts (não é possível incluir cálculos FormCalc no design de formulário).

• O JavaScript deve estar habilitado no aplicativo cliente.

O processamento pode ser executado no cliente, no servidor ou em ambos. Scripts e cálculos apresentam um comportamento diferente quando são executados no cliente e quando são executados no servidor.

Se você estiver usando um design de formulário único para criar formulários PDF e HTML, seus scripts poderão fazer referência a um subconjunto de propriedades, métodos e eventos aceitos.

As tabelas a seguir resumem quais aplicativos clientes reconhecem as diversas propriedades, métodos e eventos que podem ter referência nos scripts do cliente e/ou do servidor.

Observação 1: para caixas de listagem, formattedValue não retorna o texto exibido.

Observação 2: o evento clicar não é aceito para botões Enviar em formulários PDF ou HTML. Use preSubmit como alternativa.

Observação 3: o objeto ScriptObject pode ser criado e usado com qualquer outro script. Consulte Como criar um objeto de script.

Observação 1: para caixas de listagem, formattedValue não retorna o texto exibido.

Observação 2: o evento clicar não é aceito para botões Enviar em formulários PDF. Use preSubmit como alternativa.

Observação 3: o objeto ScriptObject pode ser criado e usado com qualquer outro script. Consulte Como criar um objeto de script.

Um subconjunto simplificado de expressões de sintaxe de referência é suportado pelos clientes HTML:

• Cálculos FormCalc não são válidos em navegadores HTML e são removidos antes da renderização do formulário em HTML.

• A sintaxe ellipsis (...) não é suportada.

• Ao gravar um script no cliente para formulários em HTML, é necessário usar a expressão resolveNode de JavaScript para localizar os nós na hierarquia. O script não pode percorrer a hierarquia usando a notação do objeto. Por exemplo, a seguinte expressão não é suportada:

      xfa.form.subform1.TextEdit1

A seguinte expressão é suportada:

xfa.form.resolveNode("subform1.TextEdit1")

Referências de campo não qualificadas podem ser usadas para localizar campos irmãos na hierarquia.

Quando o mesmo design de formulário é usado para renderizar formulários em PDF e em HTML, a configuração do tamanho da página é usada para paginar formulários em PDF, mas é ignorada quando um formulário em HTML é renderizado. Para lidar com as diferenças entre páginas em PDF e em HTML, os criadores de formulário podem usar como opção subformulários de nível de página para configurar as páginas HTML artificiais. Se as páginas HTML forem configuradas dessa forma, o JavaScript será necessário para permitir que os usuários se movimentem de uma página HTML para a próxima no tempo de execução.

É possível usar os métodos pageUp() e pageDown() para permitir que os usuários se movimentem entre páginas HTML usando um botão de comando regular que aciona o processamento quando o evento click do botão ocorrer. Para os formulários em PDF e em HTML, o processamento deve ser executado no cliente e no servidor.

Os métodos pageUp() e pageDown() operam em subformulários de nível de página. Por exemplo, presuma que o criador do formulário configurou a seguinte estrutura no design de formulário:

A.

Esse subformulário de nível de página corresponde à primeira página.

B.

Esse subformulário de nível de página corresponde à segunda página.

C.

Esse subformulário de nível de página corresponde à terceira página.

Se o usuário estiver visualizando a página HTML que corresponde ao Subform_Page0, chamar xfa.host.pageDown() faria com que o Subform_Page1 fosse exibido no navegador. Da mesma forma, chamar xfa.host.pageUp() enquanto Subform_Page1 está em exibição faria com que Subform_Page0 fosse exibido no navegador. Os números de páginas seriam atribuídos às seguintes propriedades para manipular essas páginas HTML:

xfa.host.currentPage = 0     //moves to the first page 
xfa.host.currentPage = 1     //moves to the second page 
xfa.host.currentPage = 2     //moves to the third page 
xfa.host.currentPage = xfa.host.numPages -1     //moves to the last page

À medida que os usuários se movimentam entre as páginas HTML, o estado dos dados é mantido, mas o estado da apresentação de um objeto (por exemplo, a cor de plano de fundo de um campo) pode mudar de uma página para outra. É possível manter as configurações da apresentação entre as páginas usando campos ocultos que contêm valores de estado para as diversas configurações e botões de comando que permitem que os usuários se movimentem para frente e para trás nas páginas do formulário. Seu script atualizaria os estados de apresentação dos campos com base nos valores dos campos ocultos. Quando um usuário clica em um dos botões de comando, o evento calculate para o botão poderia ser usado para executar o script.

Por exemplo, o seguinte JavaScript mantém a cor de preenchimento de um campo com base no valor de um campo chamado hiddenField. O script é acionado quando o evento calculate ocorre.

If (hiddenField.rawValue == 1) 
this.fillColor = "255,0,0" 
else 
this.fillColor = "0,255,0"