Transcript
Page 1: Protótipos de Projetos Lumis

Tutorial:

Protótipos de Projetos Lumis

Este documento visa expor uma metodologia específica para a criação de protótipos de projetos para o Lumis Portal Suite (LPS, usado em servidores Microsoft) e para o Lumis Portal Java (LPJ, usado em servidores Java), focando no desenvolvimento de protótipos HTML prontos para serem usados no Lumis, com o mínimo ajuste de código possível. Na medida em que mais e mais desenvolvedores Lumis aderirem a essa metodologia, ficará mais simples o intercâmbio de conhecimento (por exemplo, através do Lumis Information Exchange, o LINX: http://linx.lumis.com.br) e as manutenções posteriores ao lançamento dos projetos.

1. Interfaces de serviço No Lumis entendemos por interface de serviço o resultado visual final que monta uma dada interface. Como em HTML só podemos montar estruturas em caixas (sejam elas em <div>, <table>, <p>, <h1>, etc.), a grande maioria das interfaces de serviço montará visualmente uma caixa. E como o código HTML é lido de cima para baixo, a “ponta” superior esquerda da caixa corresponderá ao início do código de uma interface, e a “ponta” inferior direita corresponderá ao final do código de uma interface. Talvez o entendimento fique mais simples visualizando a imagem abaixo:

Imagem 1.1: Esta inferface de um serviço de destaque da Página Inicial do R7.com é um bom exemplo compatível com a maior parte das interfaces de serviços Lumis. O código HTML final é lido de cima (topo a esquerda) para baixo (abaixo a direita).

Page 2: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 2

Como tanto no LPS quanto no LPJ temos o controle total do código gerado dentro de uma interface de serviço, através da edição de seu XSL, em nosso protótipo HTML devemos apenas ter o cuidado de demarcar onde começa o código de cada interface, de preferência com comentários no estilo “início/fim” ou “abre interface/fecha interface”. Por exemplo: <!-- BEGIN LOGO -->

<h1 id="logo">Minha logomarca</h1>

<!-- END LOGO -->

Ou mesmo: <!-- LOGO --> <h1 id="logo">Minha logomarca</h1>

<!-- /LOGO -->

Nesse sentido, o mais importante é já ter ao início da criação do protótipo HTML um wireframe bem definido sobre como serão montadas as interfaces de serviços do projeto: quais serão código HTML estático (podendo ser montadas simplesmente em serviços HTML no Lumis), quais serão serviços padrão do Lumis (como Barra de Navegação, Matérias, Enquete, etc.), quais serão serviços customizados para o projeto (como aquele destaque para o R7, na imagem 1.1), e quais chamarão integração por iframes, flash, applets, etc. (estes geralmente podem ser apenas imagens de marcação no HTML de protótipo).

Page 3: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 3

1.1 Interfaces de serviço complexas Interfaces de serviço complexas geralmente trazem “uma interface dentro da outra”, de maneira que o código HTML do protótipo precisa já ser montado considerando essas limitações. Uma interface precisa ser montada “dentro de outra” sempre que ela precisa aparecer entre o início e o fim do código de outra interface. Nesse caso o entendimento fica bem mais simples se visualizarmos através de imagens:

Imagem 1.2: Muitas vezes, por razões técnicas, precisamos montar um protótipo HTML que considere interfaces complexas, quando uma interface precisa vir montada “dentro da outra”. É sempre recomendável já prever todas essas situações ainda no wireframe, de modo que o protótipo HTML já as levará em consideração. A solução, nesses casos, é tentar separar a interface “que envolve a outra” em blocos. Por exemplo, no caso do exemplo na imagem 1.2, a interface de Agenda do Dia poderia vir separada em dois blocos: o primeiro bloco montaria apenas o ícone e o título, e traria um <div> sem borda abaixo. O segundo bloco viria somente após o fim da interface de Texto Simples, e montaria o calendário dentro de um <div> sem borda acima. Se o primeiro bloco não tiver conteúdo cadastrável (ou seja, se o título “Agenda do Dia” puder ser escrito hard-coded diretamente no código), ele poderá até mesmo ser montado por uma interface de serviço HTML no Lumis. Se, no entanto, o conteúdo precisar ser cadastrável (ou seja, conteúdo dinâmico), não teremos como evitar o uso de 2 XSLs para montar os dois blocos da interface. É preciso levar em consideração que a mesma interface “visual” que vemos na imagem, será montada por duas interfaces de serviços distintas no Lumis, correspondendo a cada bloco que mencionamos acima. O ideal nesses casos é que o código HTML do protótipo seja bem comentado, explicando a necessidade de separação da interface em blocos:

Page 4: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 4

<!-- Agenda do Dia precisou ser dividida em 2 blocos --> <!-- AGENDA, bloco 1 -->

<div class="agenda_bloco1">

<h1>Agenda do Dia</h1>

</div>

<!-- /AGENDA, bloco 1 -->

<!-- TEXTO SIMPLES -->

<div class="agenda_texto">

<p>Lula inaugura hoje sindicato em São Paulo</p>

</div>

<!-- /TEXTO SIMPLES -->

<!-- AGENDA, bloco 2 -->

<div class="agenda_bloco2">

<!-- o código que monta o calendário entra aqui -->

</div>

<!-- /AGENDA, bloco 2 -->

Repare que esse tipo de situação também tem impacto na forma como é montado o CSS do projeto. Seria inútil ter uma classe que montasse toda a caixa de Agenda do Dia como um único <div>, por mais que esta fosse a melhor forma de montar, visto que nesse caso não temos como passar por cima de uma limitação de arquitetura do projeto. Então, a melhor solução é montar logo 3 classes distintas: “agenda_bloco1” para o topo, “agenda_texto” para a interface de texto simples, e “agenda_bloco2” para o calendário. 1.2 “Teleporte de HTML” Alguns casos são tão complexos que não admitem sequer a solução dada acima (1.1), de separar a interface em blocos. Nesses casos a única solução é o uso do procedimento de “teleporte de HTML”, que no final das contas não é algo tão ruim quanto parece, mas que ainda assim só deve ser usado em último caso. "Teleporte de HTML", ou "innerHTML teleport", é o nome curioso pelo qual certos desenvolvedores chamam o procedimento de se chamar o innerHTML de um <div> escondido em outro <div> visível, que está sendo chamado em outro local do código. Ele também pode ser usado para montar certos layouts "impossíveis" no LPS, quando o uso de colspan e/ou rowspan não é suficiente para resolver o problema (falaremos sobre isso mais adiante). Vejamos um exemplo: <p>A caixa logo abaixo...

<div id="showSource"></div>

...deveria vir abaixo desta linha, mas o script de innerHTML a

"teleportou" para cima.</p>

Page 5: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 5

<div id="source" style="display:none;">

<div style="margin:20px 0;border:1px solid

#ccc;background:#f2f2f2;width:200px;height:200px;padding:4px;">

&#160;

<p><a href="http://www.lumis.com.br"

target="_blank">Link</a></p>

</div>

</div>

<script type="text/javascript">

if(document.getElementById("showSource")) { document.getElementById("showSource").innerHTML=document.getElementById("source").innerHTML; }

</script>

No exemplo acima, todo o código dentro do <div> com ID "source" e escondido através de CSS (style="display:none;") é chamado, como uma cópia, no outro <div> com ID "showSource", e que está visível. A vantagem desse tipo de procedimento é que o <div> de ID "showSource" pode ser chamado em qualquer local, mesmo dentro do XSL de uma outra interface. Ou seja: montamos uma interface em qualquer local da página, deixamos ela escondida com CSS, e chamamos o seu código dentro do XSL de outra interface. Usando esse procedimento, praticamente qualquer layout pode ser montado com o Lumis. *** Uma variação desse código leva em consideração a questão de ele só funcionar com o JavaScript do browser habilitado. Neste caso, é melhor não esconder o <div> de ID "source" usando CSS, e sim JavaScript - dessa forma, com o JavaScript do browser desabilitado, a interface não será “teleportada”, mas da mesma forma não será escondida, o que possibilitará ainda alguma forma de interação e navegação no site, mesmo que não seja a ideal. Vejamos o código: <p>A caixa logo abaixo...

<div id="showSource"></div>

...deveria vir abaixo desta linha, mas o script de innerHTML o

"teleportou" para cima.</p>

<div id="source">

<div style="margin:20px 0;border:1px solid

#ccc;background:#f2f2f2;width:200px;height:200px;padding:4px;">

&#160;

<p><a href="http://www.lumis.com.br"

target="_blank">Link</a></p>

</div>

</div>

Page 6: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 6

<script type="text/javascript">

if(document.getElementById("showSource")) { document.getElementById("source").style.display="none"; document.getElementById("showSource").innerHTML=document.getElementById("source").innerHTML; }

</script>

<noscript>Você precisa ter o JavaScript habilitado no browser

para ter uma visualização ideal desta página.</noscript>

Caso o “teleporte de HTML” seja definido como solução final ainda no wireframe ou na construção do protótipo HTML do projeto, o ideal é deixar o código já montado com os <div>s e seus respectivos IDs, assim como os scripts de “teleporte” – Tudo o que pode ser montado e testado ainda no protótipo HTML é preferível a opção de descobrir os erros somente quando já estamos montando o projeto no Lumis, mexendo com montagem e XSLs de serviços.

Page 7: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 7

2. Estrutura de arquivos Um dos objetivos de se criar protótipos em HTML para projetos Lumis também é já deixar os arquivos estáticos – css, javascript, flash, etc. – organizados em estruturas de pastas que serão as mesmas utilizadas no servidor final. Dessa forma, chamadas para arquivos como, por exemplo, nas tags de imagem (<img src=”image.gif” />), já chamarão as imagens no caminho correto, e quando o desenvolvedor for criar os XSLs a partir desses HTMLs de protótipo, não precisará se preocupar em converter os caminhos um por um. No entanto, essa será apenas nossa sugestão para a organização de arquivos. Muitas empresas têm um procedimento específico para a criação de estruturas de arquivos e suas nomenclaturas. Se não for possível seguir nossa sugestão, de qualquer forma ainda é muito importante que sigam, em seu protótipo HTML, a mesma estrutura que usarão no servidor final do projeto. 2.1 Estrutura de arquivos no Lumis Portal Suite Os arquivos no LPS devem ficar organizados a partir da pasta root (no caso, a pasta “/release”), que no servidor final será a mesma pasta onde encontramos o arquivo “main.asp”, pois todas as chamadas para imagens e outros arquivos partem dali. Todos os HTMLs criados para o protótipo devem ficar nessa mesma pasta, e a partir dela criaremos uma outra pasta com um nome abreviado do projeto, podendo mesmo ser um acrônimo (ex: um projeto para uma seguradora chamada “Big Bird Seguros” poderia usar o acrônimo “bbs” para nomear a pasta com os arquivos do projeto). Recomendamos que todos os nomes de pastas sejam escritos em caixa baixa. Dentro da pasta do projeto, criaremos mais quatro pastas, conforme as sugestões abaixo: A. Na pasta “css” incluiremos os arquivos .css (“Cascading StyleSheets”) B. Na pasta “images” incluiremos os arquivos de imagens – geralmente: .gif, .jpg ou .png C. Na pasta “js” incluiremos os arquivos .js (“JavaScript”) D. Na pasta “media” incluiremos os arquivos de mídia, incluindo vídeos e aplicativos – os mais comuns são os arquivos .swf (“ShockWave/Flash”)

Page 8: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 8

Quando terminar de criar a estrutura, ela deverá parecer assim no seu Windows Explorer:

Imagem 2.1: Estrutura final de pastas para arquivos de css, imagens, js e mídia no protótipo HTML para um projeto em LPS. A pasta “release” é a pasta root, onde temos o main.asp – o arquivo “home.html” é apenas um dos inúmeros HTMLs que poderão ser montados para este protótipo, e todos eles precisam ficar na mesma pasta “release”. Repare que na imagem acima escolhemos um nome genérico para a pasta do projeto: “project”. É este nome que precisa ser ajustado para refletir o nome do seu projeto (de preferência abreviando nomes grandes). Nos HTMLs de protótipo, é assim que chamaremos, por exemplo, uma imagem intitulada “image.gif”: <img src="project/images/image.gif" />

Já um arquivo css intitulado “project.css” seria chamado da seguinte forma nos HTMLs de protótipo: <link href="project/css/project.css" type="text/css" media="screen" />

2.2 Estrutura de arquivos no Lumis Portal Java Os arquivos no LPJ devem ficar organizados a partir da pasta root (no caso, a pasta “/www”), que no servidor final será a mesma pasta onde encontramos o arquivo “main.jsp”, pois todas as chamadas para imagens e outros arquivos partem dali. Todos os HTMLs criados para o protótipo devem ficar nessa mesma pasta, e a partir dela criaremos uma outra pasta com um nome abreviado do projeto, podendo mesmo ser um acrônimo (ex: um projeto para uma seguradora chamada “Big Bird Seguros” poderia usar o acrônimo “bbs” para nomear a pasta com os arquivos do projeto). Recomendamos que todos os nomes de pastas sejam escritos em caixa baixa. Dentro da pasta do projeto, criaremos mais quatro pastas, conforme as sugestões abaixo: A. Na pasta “css” incluiremos os arquivos .css (“Cascading StyleSheets”) B. Na pasta “images” incluiremos os arquivos de imagens – geralmente: .gif, .jpg ou .png C. Na pasta “js” incluiremos os arquivos .js (“JavaScript”)

Page 9: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 9

D. Na pasta “media” incluiremos os arquivos de mídia, incluindo vídeos e aplicativos – os mais comuns são os arquivos .swf (“ShockWave/Flash”) Quando terminar de criar a estrutura, ela deverá parecer assim no seu Windows Explorer (ou algum programa similar no Linux):

Imagem 2.2: Estrutura final de pastas para arquivos de css, imagens, js e mídia no protótipo HTML para um projeto em LPJ. A pasta “www” é a pasta root, onde temos o main.jsp – o arquivo “home.html” é apenas um dos inúmeros HTMLs que poderão ser montados para este protótipo, e todos eles precisam ficar na mesma pasta “www”. Repare que na imagem acima escolhemos um nome genérico para a pasta do projeto: “project”. É este nome que precisa ser ajustado para refletir o nome do seu projeto (de preferência abreviando nomes grandes). Nos HTMLs de protótipo, é assim que chamaremos, por exemplo, uma imagem intitulada “image.gif”: <img src="project/images/image.gif" />

Já um arquivo css intitulado “project.css” seria chamado da seguinte forma nos HTMLs de protótipo: <link href="project/css/project.css" type="text/css"

media="screen" />

Page 10: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 10

3. Regras de XHTML Todo HTML criado no protótipo deve ser compatível com as exigências do XHTML, pois assim ele também será compatível com o XSL. Abaixo incluímos resumidamente as regras para se escrever código XHTML válido: A. Todas as tags devem ser fechadas. Ou seja, se você usar um <span> terá de fechá-lo sempre com um </span> ou o arquivo ficará incorreto. Lembramos também que mesmo tags que não costumam “abrir e fechar” tem de ser fechadas. Isso ocorre com o <br> por exemplo, que deve ser usado como <br></br>, ou sua forma abreviada <br/> B. Todas as tags devem ser abertas e fechadas respeitando sua ordenação. Ou seja, se você quer envolver um texto com as tags <b> e <span> por exemplo, deve fazer dessa forma: <span><b>Texto</b></span>. Caso faça em outra ordem, o arquivo ficará incorreto, como por exemplo: <span><b>Texto</span></b> (Note que aqui o <span> foi fechado antes do <b>, daí o erro). C. Todas as tags devem ser escritas em caixa baixa. Ou seja, <table> irá funcionar, enquanto <TABLE> ou <Table> deixará o arquivo incorreto. D. Todas os atributos de uma tag devem vir entre aspas duplas. Ou seja, <table cellpadding=”0” cellspacing=”0”> irá funcionar, enquanto <table cellpadding=0 cellspacing=0> deixará o arquivo incorreto. E. Deveremos usar códigos específicos para caracteres especiais. Aqui ocorre um problema mais grave, pois muitos estão acostumados com os códigos de caracteres especiais do HTML, como o &nbsp; para representar espaço em branco. No XSL &nbsp; não irá funcionar, e devemos usar &#160; no lugar. Felizmente temos bastante material disponível sobre isso na web, recomendamos este como referência rápida: http://www.cssplay.co.uk/menu/code.html 3.1 Validação de XHTML Após terminar alguns trechos de seus HTMLs, é recomendável ir validando online para verificar se não existe algum erro de XHTML: http://validator.w3.org/ Alguns programas de edição de código podem vir com validadores XHTML embutidos, o que pode facilitar o processo.

Page 11: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 11

4. HTML de protótipo Esta é a parte mais importante deste tutorial, pois trará informações detalhadas sobre como montar seu HTML de protótipo. Os códigos aqui utilizados podem servir de base para o início do trabalho, poupando tempo. A função principal desses códigos é prever o HTML que o Lumis insere automaticamente em torno das interfaces de serviço em uma página. A menos que você use o Lumis Portal Java com Template Files, não terá controle total sobre esse HTML e, portanto, seu protótipo precisará replicar o que o Lumis monta automaticamente. Na realidade o Lumis monta muito mais código do que o exposto nos exemplos abaixo, porém estamos focando apenas no código “mínimo”, ou seja, aqueles trechos de HTML que realmente irão influenciar a estrutura da visualização final. Por exemplo, em torno de cada interface no LPS e no LPJ em modo de layout Com Tabelas, são montadas novas tabelas dentro das já existentes, e que são consideradas em nossos exemplos abaixo; Porém, essas tabelas não interferem em nada na estrutura final do layout, por isso optamos por ignorá-las, juntamente com todo o código adicional que não influi no resultado final dentro do Lumis. 4.1 HTML de protótipo para o Lumis Portal Suite O LPS não possui modo de layout Sem Tabelas, como no LPJ; Portanto, qualquer projeto feito nele não poderá ser Tableless, já que o Lumis montará automaticamente tabelas em torno das interfaces de serviço inseridas nas páginas. Vejamos abaixo um exemplo de código HTML inicial para protótipos de projetos em LPS: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html>

<head>

<title>Lumis Project</title>

<link href="project/css/project.css" type="text/css"

media="screen" />

<style type="text/css" media="screen"> div.box {background:#f9f9f9;border:1px solid #ccc;padding:5px;} </style>

</head>

Page 12: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 12

<body class="cEZTBody">

<div class="cEZTPage">

<table cellpadding="0" cellspacing="0" width="770"

class="cEZTPageArea0"> <tr valign="top">

<td width="770" class="cEZTPageArea0Column0">

<!-- HEADER -->

<div class="box">HTML para primeira interface Lumis (ex: interface html montando cabeçalho).</div>

<!-- /HEADER -->

</td>

</tr>

</table>

<table cellpadding="0" cellspacing="0" width="770"

class="cEZTPageArea1">

<tr valign="top">

<td width="190" class="cEZTPageArea1Column0">

<!-- MENU -->

<div class="box">HTML para segunda interface Lumis (ex: barra de navegação).</div>

<!-- /MENU -->

</td>

<td width="580" class="cEZTPageArea1Column1">

<!-- NEWS LIST -->

<div class="box">HTML para terceira interface Lumis (ex: lista de notícias).</div>

<!-- /NEWS LIST -->

</td>

</tr>

</table>

</div>

</body>

</html>

Algumas notas sobre o código acima: A. Marcados em verde, estão os trechos de código que montam as caixas de teste, somente para que possa ser visualizado o espaço que cada interface irá ocupar. Tanto o estilo aplicado dentro da tag <style> dentro do <head> quanto os códigos que montam os <div class=”box”> podem ser deletados assim que começar a trabalhar usando este código como base inicial.

Page 13: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 13

B. Repare que o DOCTYPE está configurado para XHTML Transitional, se quiser usar XHTML Strict em seu projeto, é recomendável que mude já no protótipo HTML, pois algumas inconsistências podem aparecer quando mudar de um DOCTYPE para o outro. C. Marcados em vermelho, estão às classes que o Lumis insere automaticamente no código final. Elas são: cEZTBody Esta classe serve para que possamos aplicar layout css na tag <body>. Não é possível adicionar outra classe nesta tag, nem utilizar outro título de classe, pois o LPS não permite. cEZTPage Esta classe serve para que possamos aplicar layout css na tag <div> em torno de toda a estrutura, ou seja: imediatamente após a tag <body>. Normalmente utilizado para centralizar o layout por css, embora possa servir também para aplicar bordas e espaçamentos globais. Não é possível adicionar outra classe nesta tag, nem utilizar outro título de classe, pois o LPS não permite. cEZTPageAreaX, cEZTPageAreaXColumnY (Classes Genéricas) Essas classes são inseridas automaticamente nas tabelas estruturais de acordo com a adição de áreas e colunas na página, dentro do Lumis. Falaremos sobre essas Classes Genéricas mais adiante... *** Finalmente, podemos falar sobre a lógica exposta no código. Reparem que na primeira tabela temos somente uma única interface (“HEADER”), pois ali temos uma área com uma única coluna. Já na segunda tabela temos duas interfaces (“MENU” e “NEWS LIST”), cada uma em uma coluna em separado. Estamos simplesmente replicando a estrutura que o Lumis monta automaticamente já em nosso protótipo. Cada área monta uma tabela e, dentro de uma área, ao adicionarmos novas interfaces uma ao lado da outra, novas colunas serão montadas. Dentro de uma coluna, contanto que insiramos uma interface abaixo da outra, podemos ter virtualmente quantas interfaces diferentes quisermos. Porém, quando as interfaces precisam vir uma ao lado da outra, teremos de prever a criação de novas células de tabela em nosso protótipo. Uma questão bastante importante é a marcação da largura de cada coluna, pois se estourarmos as larguras, o layout poderá quebrar. Outro detalhe é que essas larguras precisarão ser inseridas na edição de páginas e templates de páginas no Lumis, com o valor exatamente igual ao do protótipo. Recomendamos que, ainda desde o layout final (em .psd ou .png) essas larguras já estejam delimitadas e anotadas, assim o trabalho de criar o protótipo HTML ficará mais simples. Em nosso exemplo acima, a largura total do site é de 770 pixels. A primeira área, com o cabeçalho, tem apenas uma única coluna e, portanto, também tem 770 pixels. Já a segunda área (ou segunda tabela) vem com duas colunas: a coluna do MENU tem 190 pixels e a coluna de NEWS LIST tem 580 pixels. Geralmente a soma das colunas de cada área será sempre a largura total do site, ou seja: 190px + 580px = 770px.

Page 14: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 14

4.1.1 Classes Genéricas no Lumis Portal Suite O Lumis Portal Suite disponibiliza classes genéricas que podem ser aplicados no layout que é criado automaticamente pelo portal. Toda vez que criamos uma nova página no LPS, uma estrutura genérica de HTML é automaticamente criada pelo Lumis para mostrar as interfaces inclusas na página. O Lumis cria um “esqueleto” que monta o código entre as interfaces usando algumas tabelas. A boa notícia é que cada linha e célula dessas tabelas têm uma classe específica. A essas classes demos o título de Classes Genéricas. Veja abaixo um diagrama que mostra a lógica pela qual essas classes são inclusas no código HTML final:

Imagem 4.1: Diagrama que demonstra a lógica de nomenclatura das Classes Genéricas. A primeira área (ou tabela) trará a classe “cEZTPageArea0” em sua tag <table>, a segunda “cEZTPageArea1”, a terceira “cEZTPageArea2”, e assim por diante; Seguindo uma lógica parecida, cada coluna de uma área trará classes em suas tags <td>, começando por “cEZTPageAreaXColumn0” e prosseguindo – “cEZTPageAreaXColumn1”, “cEZTPageAreaXColumn2”, e assim por diante – onde “X” corresponde ao número da área em que a coluna está localizada. Geralmente usamos algumas Classes Genéricas para incluir um background ao longo de várias interfaces sem ter de editar uma por uma. Por exemplo, caso quiséssemos que todo cabeçalho de página tivesse fundo cinza, bastaria incluir esse código em nosso arquivo CSS:

Page 15: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 15

.cEZTPageArea0 {

background:#f5f5f5;

}

As Classes Genéricas nem sempre se fazem necessárias, mas podem salvar bastante trabalho na edição de um portal. Sempre tenha em mente que elas existem, apesar de não aparecerem em css nenhum – nem mesmo no webportal.css, padrão do Lumis. Nota: Usando JQuery, é possível aplicar estilos as áreas (<table>) e colunas (<td>) montadas automaticamente pelo Lumis em torno das interfaces. Para tal você precisará apenas de uma interface HTML que traga um marcador através do ID de um <div>, por exemplo: <div id="colDottedBackgroundLeft"><!-- --></div> Através desse marcador, e com algum conhecimento de JQuery, é possível “encontrar” a tag <td> imediatamente anterior a este <div> (sempre inserir a interface HTML no topo das colunas) e aplicar algum estilo a ela, como por exemplo uma borda pontilhada a esquerda (border:1px dotted #ccc;) Usando esse método o layout das páginas ficará menos “preso”, e você poderá futuramente adicionar novas áreas entre as áreas já existentes, sem precisar se preocupar em alterar a numeração de suas Classes Genéricas (na verdade, nem precisará mais utilizá-las). 4.2 HTML de protótipo para o Lumis Portal Java No LPJ, nosso HTML de protótipo deverá ser criado de acordo com o tipo de layout que será utilizado para as respectivas páginas no Lumis: Com Tabelas ou Sem Tabelas (o que permite portais Tableless). Também existe a possibilidade do uso de Template Files, o que permite um controle total do código HTML gerado, que deixaremos para falar no final deste tutorial. 4.2.1 Layout Com Tabelas Vejamos abaixo um exemplo de código HTML inicial para protótipos de projetos em LPJ no layout Com Tabelas: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html>

<head>

<title>Lumis Project</title>

<link href="project/css/project.css" type="text/css"

media="screen" />

<style type="text/css" media="screen"> div.box {background:#f9f9f9;border:1px solid #ccc;padding:5px;} </style>

</head>

Page 16: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 16

<body class="cLumBody">

<div class="cLumPage">

<table cellpadding="0" cellspacing="0" width="770"

class="anyclass">

<tr valign="top">

<td width="770">

<!-- HEADER -->

<div class="box">HTML para primeira interface Lumis (ex: interface html montando cabeçalho).</div>

<!-- /HEADER -->

</td>

</tr>

</table>

<table cellpadding="0" cellspacing="0" width="770"

class="areaclass">

<tr valign="top">

<td width="190" class="columnclass">

<!-- MENU -->

<div class="box">HTML para segunda interface Lumis (ex: barra de navegação).</div>

<!-- /MENU -->

</td>

<td width="580">

<!-- NEWS LIST -->

<div class="box">HTML para terceira interface Lumis (ex: lista de notícias).</div>

<!-- /NEWS LIST -->

</td>

</tr>

</table>

</div>

</body>

</html>

Algumas notas sobre o código acima: A. Marcados em verde, estão os trechos de código que montam as caixas de teste, somente para que possa ser visualizado o espaço que cada interface irá ocupar. Tanto o estilo aplicado dentro da tag <style> dentro do <head> quanto os códigos que montam os <div class=”box”> podem ser deletados assim que começar a trabalhar usando este código como base inicial.

Page 17: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 17

B. Repare que o DOCTYPE está configurado para XHTML Transitional, se quiser usar XHTML Strict em seu projeto, é recomendável que mude já no protótipo HTML, pois algumas inconsistências podem aparecer quando mudar de um DOCTYPE para o outro. C. Marcados em vermelho, estão às classes que o Lumis insere automaticamente no código final. Elas são: cLumBody Esta classe serve para que possamos aplicar layout css na tag <body>. Não é possível adicionar outra classe nesta tag, nem utilizar outro título de classe, pois o LPS não permite. cLumPage Esta classe serve para que possamos aplicar layout css na tag <div> em torno de toda a estrutura, ou seja: imediatamente após a tag <body>. Normalmente utilizado para centralizar o layout por css, embora possa servir também para aplicar bordas e espaçamentos globais. Não é possível adicionar outra classe nesta tag, nem utilizar outro título de classe, pois o LPS não permite. areaclass, columnclass (Classes Livres) Essas classes são livres, já que no LPJ podemos editar as propriedades de uma área ou coluna para inserirmos o atributo “class” ou “id” que quisermos. Mesmo o título dessas classes é livre, o montador quem irá escolher. Normalmente essas classes são usadas para aplicar layouts de background ou padding (espaçamento) a todas as interfaces dentro de uma mesma área ou coluna – mas através do uso de IDs também podem servir como marcação para eventos de JavaScript. *** Finalmente, podemos falar sobre a lógica exposta no código. Reparem que na primeira tabela temos somente uma única interface (“HEADER”), pois ali temos uma área com uma única coluna. Já na segunda tabela temos duas interfaces (“MENU” e “NEWS LIST”), cada uma em uma coluna em separado. Estamos simplesmente replicando a estrutura que o Lumis monta automaticamente já em nosso protótipo. Cada área monta uma tabela e, dentro de uma área, ao adicionarmos novas interfaces uma ao lado da outra, novas colunas serão montadas. Dentro de uma coluna, contanto que insiramos uma interface abaixo da outra, podemos ter virtualmente quantas interfaces diferentes quisermos. Porém, quando as interfaces precisam vir uma ao lado da outra, teremos de prever a criação de novas células de tabela em nosso protótipo. Uma questão bastante importante é a marcação da largura de cada coluna, pois se estourarmos as larguras, o layout poderá quebrar. Outro detalhe é que essas larguras precisarão ser inseridas na edição de páginas e templates de páginas no Lumis, com o valor exatamente igual ao do protótipo. Recomendamos que, ainda desde o layout final (em .psd ou .png) essas larguras já estejam delimitadas e anotadas, assim o trabalho de criar o protótipo HTML ficará mais simples. Em nosso exemplo acima, a largura total do site é de 770 pixels. A primeira área, com o cabeçalho, tem apenas uma única coluna e, portanto, também tem 770 pixels. Já a segunda área (ou segunda tabela) vem com duas colunas: a coluna do MENU tem 190

Page 18: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 18

pixels e a coluna de NEWS LIST tem 580 pixels. Geralmente a soma das colunas de cada área será sempre a largura total do site, ou seja: 190px + 580px = 770px. 4.2.2 Layout Sem Tabelas (Tableless) Recomendamos alguma experiência com projetos em layout Com Tabelas antes de entrar num projeto com layout Sem Tabelas. Se este é seu primeiro contato com o Lumis, no entanto, pelo menos leia o que dissemos em 4.2.1, que irá ajudar bastante na compreensão do que diremos abaixo. Vejamos abaixo um exemplo de código HTML inicial para protótipos de projetos em LPJ no layout Sem Tabelas: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html>

<head>

<title>Lumis Project</title>

<link href="project/css/project.css" type="text/css"

media="screen" />

<style type="text/css" media="screen">

div.box {background:#f9f9f9;border:1px solid #ccc;padding:5px;}

/*isso pode ser usado para anular classes automáticas aplicadas ao código final*/ div.cLumArea, div.cLumColumn {float:none;} br.cLumAreaSeparator, br.cLumRowSeparator {clear:none;display:none;} /*assim você pode usar classes próprias para o projeto...*/ div.columnclass {float:left;}

</style>

</head>

<body class="cLumBody">

<div class="cLumPage">

<div class="cLumArea areaclass"> <div class="cLumColumn columnclass">

<!-- HEADER -->

<div class="box">HTML para primeira interface Lumis (ex: interface html montando cabeçalho).</div>

<!-- /HEADER -->

</div>

</div>

<br class="cLumAreaSeparator" />

<div class="cLumArea areaclass"> <div class="cLumColumn columnclass">

Page 19: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 19

<!-- MENU -->

<div class="box">HTML para segunda interface Lumis (ex:barra de navegação).</div>

<!-- /MENU -->

</div>

<div class="cLumColumn columnclass">

<!-- NEWS LIST -->

<div class="box">HTML para terceira interface Lumis (ex:lista de notícias).</div> <!-- /NEWS LIST -->

</div>

</div>

<br class="cLumAreaSeparator" />

</div>

</body>

</html>

Algumas notas sobre o código acima: A. Marcados em verde, estão os trechos de código que montam as caixas de teste, somente para que possa ser visualizado o espaço que cada interface irá ocupar. Tanto o estilo aplicado dentro da tag <style> dentro do <head> quanto os códigos que montam os <div class=”box”> podem ser deletados assim que começar a trabalhar usando este código como base inicial. B. Repare que o DOCTYPE está configurado para XHTML Transitional, se quiser usar XHTML Strict em seu projeto, é recomendável que mude já no protótipo HTML, pois algumas inconsistências podem aparecer quando mudar de um DOCTYPE para o outro. C. Marcados em vermelho, estão às classes que o Lumis insere automaticamente no código final. Elas são: cLumBody Esta classe serve para que possamos aplicar layout css na tag <body>. Não é possível adicionar outra classe nesta tag, nem utilizar outro título de classe, pois o LPS não permite. cLumPage Esta classe serve para que possamos aplicar layout css na tag <div> em torno de toda a estrutura, ou seja: imediatamente após a tag <body>. Normalmente utilizado para centralizar o layout por css, embora possa servir também para aplicar bordas e espaçamentos globais. Não é possível adicionar outra classe nesta tag, nem utilizar outro título de classe, pois o LPS não permite. cLumArea Esta classe é inserida automaticamente em todo <div> que monta uma área no Lumis. Este <div> é o correspondente do <table> montado para cada área no layout Com

Page 20: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 20

Tabelas. Esta classe vem com o atributo float:left; aplicado pelo css padrão do LPJ (portal.css), caso queira anular o float, use em seu css: div.cLumArea {float:none;}

cLumColumn Esta classe é inserida automaticamente em todo <div> que monta uma coluna no Lumis. Este <div> é o correspondente do <td> montado para cada coluna no layout Com Tabelas. Esta classe vem com o atributo float:left; aplicado pelo css padrão do LPJ (portal.css), caso queira anular o float, use em seu css: div.cLumColumn {float:none;}

cLumAreaSeparator Esta classe é aplicada em tags <br /> ao final de cada <div class=”cLumArea”> montado automaticamente a medida que adicionamos áreas novas a página pela edição dentro do Lumis. Esta class vem com o atributo cler:both; aplicado pelo css padrão do LPJ (portal.css), e serve para dar clear nos floats das tags <div> montando colunas acima. Caso queira anular o clear, use em seu css: br.cLumAreaSeparator {clear:none;}

Porém, o mais recomendado é simplesmente não mostrar essas tags <br />, evitando causar espaçamentos indevidos entre as interfaces de serviço: br.cLumAreaSeparator, br.cLumRowSeparator

{clear:none;display:none;}

Repare que o código acima precisa ser utilizado ainda que você não aplique o css padrão do LPJ em seu projeto, já que as tags <br /> são montadas automaticamente pelo Lumis. No HTML de exemplo acima não incluímos as tags <br /> com classe cLumRowSeparator porque elas não interferem na visualização final do layout. Se quiser “sumir” com essas tags <br />, entretanto, recomendamos que aplique o display:none; logo em ambas, conforme o trecho de css logo acima. areaclass, columnclass (Classes Livres) Essas classes são livres, já que no LPJ podemos editar as propriedades de uma área ou coluna para inserirmos o atributo “class” ou “id” que quisermos. Mesmo o título dessas classes é livre, o montador quem irá escolher. Normalmente essas classes são usadas para aplicar layouts de background ou padding (espaçamento) a todas as interfaces dentro de uma mesma área ou coluna – mas através do uso de IDs também podem servir como marcação para eventos de JavaScript. D. Marcados em roxo, estão os trechos de css sugeridos para que anulemos os atributos vindos do css padrão do LPJ (portal.css), assim como “fazer sumir” as tags <br /> montadas automaticamente pelo Lumis, e que talvez causem espaçamentos desnecessários. É exatamente sobre isso que falamos logo acima na letra C. *** Finalmente, podemos falar sobre a lógica exposta no código. A versão de layout Sem Tabelas do LPJ tenta simular o layout criado com tabelas inserindo floats através de classes css (float:left;). Basicamente toda área monta um <div> com classe cLumArea, e toda coluna monta um outro <div> com classe cLumColumn dentro do <div> da área.

Page 21: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 21

Após o término de cada área o Lumis insere automaticamente o <br class=”cLumAreaSeparator” /> para dar clear nesses floats. Isso até funciona bem para layouts básicos, mas dificilmente vai abranger layouts um pouco mais complexos. Nesses casos, sugerimos que as classes vindas do css padrão do LPJ sejam anuladas (ver letras C e D acima), ou preferivelmente que o css padrão sequer seja aplicado no projeto (ainda assim é preciso “sumir” com as tags <br /> de separação). Felizmente, o LPJ permite que apliquemos nossas próprias classes as áreas e colunas. Isso significa que toda interface de serviço poderá ter até duas tags <div /> com classes específicas em torno – uma para coluna e outra para a área –, porém não mais do que isso. Ainda assim, a maior parte dos layouts poderá ser montada sem problemas. Se por alguma razão precisar ter mais de duas tags <div /> com classes específicas em torno de uma única interface de serviço, sugerimos usar o “teleporte de HTML” descrito em 1.2, ou usar Template Files para ter controle total do código gerado em torno das interfaces (ainda falaremos sobre eles a seguir). 4.3 Sobre o evento de onLoad na tag <body> Outra questão importante a ser considerada no protótipo HTML – e isto vale tanto para códigos formulados para o LPS quanto para o LPJ – é nunca usar o evento de onLoad da tag <body>, ou seja, o <body onload=”javascript:someEvent();”>. Isto porque o Lumis precisa deste evento para que os scripts padrão do produto rodem normalmente. Eles são vitais para o correto funcionamento da edição F12, assim como diversas funcionalidades padrão de certos serviços. Caso precise usar este evento de qualquer maneira em seu projeto, recomendamos entrar em contato com o suporte da Lumis. Antes, porém, verifique se não existem outras possibilidades – por exemplo, muitos menus drop-down usam o evento de onLoad no <body> para funcionar. Isso, no entanto, pode facilmente ser contornado se inserirmos o mesmo script em uma tag <div> que esteja em torno do menu, porém usando o evento de onMouseOver no lugar de onLoad. Como todo menu drop-down depende de onMouseOver para iniciar a animação do drop-down, não há problema na transferência.

Page 22: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 22

5. Template Files No Lumis Portal Java, a partir das versões lançadas no final de 2009 em diante, passamos a poder utilizar Template Files em projetos no Lumis. Os Template Files são arquivos .html aplicados a páginas do Lumis que substituem a geração automática de HTML do Lumis em torno das interfaces, colunas e áreas. Eles representam uma customização completa de layout no produto, deixando o HTML praticamente 100% livre para edição. A lógica dos Template Files é simples: eles montam uma página .html comum, podendo inclusive ser gerados diretamente a partir dos HTMLs originais dos protótipos de projetos. Onde temos o HTML “hard-coded”, não-dinâmico, montando o layout das interfaces de serviço, bastará substituir o bloco de código que monta a interface correspondente por uma chamada específica para um ID (identificador único). Na edição da página ou template de página do Lumis, editaremos uma coluna de modo a inserir este mesmo ID, e todas as interfaces de serviço inseridas na coluna entrarão no código final exatamente onde está a chamada para este ID. Isso significa também que, para projetos onde usamos Template Files, apenas essas regras se aplicam para a criação do HTML de protótipo: A. Conforme dito em 4.3, continua sendo proibido utilizar o evento de onLoad da tag <body> B. Conforme dito ao longo do capítulo 1, é preciso demarcar corretamente o início e fim do código HTML para cada interface de serviço, montando o css de acordo e, principalmente, levando em consideração as interfaces complexas (ver 1.1) existentes no wireframe. *** Certamente, são bem menos regras a serem consideradas. Porém, o uso de Template Files requer maior conhecimento de HTML e css da parte dos montadores no Lumis, de modo que não irá adiantar muito facilitar a criação de protótipos HTML pelo uso de Template Files, se na hora de passar o protótipo para o Lumis os montadores tiverem dificuldades em lidar com os Template Files.

Page 23: Protótipos de Projetos Lumis

Protótipos de Projetos Lumis Página 23

6. Porque criar protótipos HTML para projetos Lumis Além dos motivos óbvios que levam todos os desenvolvedores a montar protótipos HTML para seus projetos web, a prática de criar HTML já adaptado para o uso no Lumis tem por objetivo facilitar, e muito, a posterior montagem do projeto dentro do Lumis. Ocorre que a lógica de trabalho quando estamos desenvolvendo HTML e css é bem distinta da lógica de montagem dentro do Lumis. Na primeira, estaremos mais preocupados em criar código HTML limpo e com css bem estruturado, testar o layout localmente e em diversos browsers diferentes, sempre a procura de erros de layout a serem corrigidos; Já na última, estaremos preocupados em criar estruturas de canais e páginas, instanciar serviços e criar as respectivas administrações, criar XSLs com chamadas dinâmicas a partir do código HTML estático do protótipo, verificar controle de acesso de usuários, se todos os formulários estão funcionais, etc. Ou seja, são lógicas e procedimentos de trabalho suficientemente distintos para que, ainda que sejam os mesmos desenvolvedores a cuidar tanto do HTML do protótipo quanto da montagem no Lumis, valha a pena fazer uma coisa de cada vez, evitando confusão e re-trabalho desnecessários. Sabemos que muitas vezes os prazos curtos impedirão que todos os procedimentos sugeridos nesse tutorial sejam seguidos de acordo, mas em todo caso o importante é compreender que um planejamento inicial, desde um wireframe que já leve em consideração quais serviços Lumis serão usados em cada “bloco” de layout, até um protótipo HTML previamente ajustado para o Lumis, serão sempre bem vindos, e nunca um tempo gasto desnecessariamente. Boa sorte!


Top Related