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).
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:


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

Ou mesmo:


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

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).
Protótipos de Projetos Lumis Página 2

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:



<div class="agenda_bloco1">
<h1>Agenda do Dia</h1>
</div>



<div class="agenda_texto">
<p>Lula inaugura hoje sindicato em São Paulo</p>
</div>



<div class="agenda_bloco2">

</div>

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>

<div id="source" style="display:none;">
<div style="margin:20px 0;border:1px solid
#ccc;background:#f2f2f2;width:200px;height:200px;padding:4px;">

<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.ge
tElementById("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;">

<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("source").style.display="none";
document.getElementById("showSource").innerHTML=document.getElem
entById("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.

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”)

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”)

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:

media="screen" />

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 para representar espaço em branco.
No XSL não irá funcionar, e devemos usar 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.

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>
media="screen" />
<style type="text/css" media="screen">

div.box {background:#f9f9f9;border:1px solid
#ccc;padding:5px;}
</style>
</head>

<body class="cEZTBody">
<div class="cEZTPage">
<table cellpadding="0" cellspacing="0" width="770"

class="cEZTPageArea0">
<tr valign="top">
<td width="770" class="cEZTPageArea0Column0">


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

</td>
</tr>
</table>

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


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

</td>


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

</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.

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.

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:

.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

LPJ no layout Com Tabelas:

<html>
<head>
media="screen" />

#ccc;padding:5px;}
</style>
</head>

<body class="cLumBody">
<div class="cLumPage">

class="anyclass">
<tr valign="top">
<td width="770">


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

</td>
</tr>
</table>

class="areaclass">
<tr valign="top">
<td width="190" class="columnclass">


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

</td>
<td width="580">


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

</td>
</tr>
</table>
</div>
</body>
</html>


outro.

cLumBody
não permite.
cLumPage
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

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.

LPJ no layout Sem Tabelas:

<html>
<head>
media="screen" />

#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">


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

</div>
</div>
<br class="cLumAreaSeparator" />
<div class="cLumArea areaclass">



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

</div>


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

</div>
</div>
<br class="cLumAreaSeparator" />
</div>
</body>
</html>

outro.

cLumBody
não permite.
cLumPage
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

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.

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.

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.

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!

Protótipos de Projetos Lumis

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Protótipos de Projetos Lumis

Enviado por

Direitos autorais:

Formatos disponíveis

Tutorial:

Protótipos de Projetos Lumis

Imagem 1.1: Esta inferface de um serviço de destaque da Página Inicial do R7.com é

Nesse sentido, o mais importante é já ter ao início da criação do protótipo HTML um

Protótipos de Projetos Lumis Página 2

Interfaces de serviço complexas geralmente trazem “uma interface dentro da outra”, de

Protótipos de Projetos Lumis Página 3

1.2 “Teleporte de HTML”

"Teleporte de HTML", ou "innerHTML teleport", é o nome curioso pelo qual certos

<p>A caixa logo abaixo...

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

Protótipos de Projetos Lumis Página 4

No exemplo acima, todo o código dentro do <div> com ID "source" e escondido

A vantagem desse tipo de procedimento é que o <div> de ID "showSource" pode ser

<p>A caixa logo abaixo...

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

Protótipos de Projetos Lumis Página 5

Protótipos de Projetos Lumis Página 6

2.1 Estrutura de arquivos no Lumis Portal Suite

Dentro da pasta do projeto, criaremos mais quatro pastas, conforme as sugestões

A. Na pasta “css” incluiremos os arquivos .css (“Cascading StyleSheets”)

B. Na pasta “images” incluiremos os arquivos de imagens – geralmente: .gif, .jpg ou

C. Na pasta “js” incluiremos os arquivos .js (“JavaScript”)

D. Na pasta “media” incluiremos os arquivos de mídia, incluindo vídeos e aplicativos –

Protótipos de Projetos Lumis Página 7

<img src="project/images/image.gif" />

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

2.2 Estrutura de arquivos no Lumis Portal Java

Dentro da pasta do projeto, criaremos mais quatro pastas, conforme as sugestões

A. Na pasta “css” incluiremos os arquivos .css (“Cascading StyleSheets”)

B. Na pasta “images” incluiremos os arquivos de imagens – geralmente: .gif, .jpg ou

C. Na pasta “js” incluiremos os arquivos .js (“JavaScript”)

Protótipos de Projetos Lumis Página 8

<img src="project/images/image.gif" />

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

Protótipos de Projetos Lumis Página 9

A. Todas as tags devem ser fechadas.

B. Todas as tags devem ser abertas e fechadas respeitando sua ordenação.

C. Todas as tags devem ser escritas em caixa baixa.

D. Todas os atributos de uma tag devem vir entre aspas duplas.

E. Deveremos usar códigos específicos para caracteres especiais.

3.1 Validação de XHTML

Protótipos de Projetos Lumis Página 10

A função principal desses códigos é prever o HTML que o Lumis insere

4.1 HTML de protótipo para o Lumis Portal Suite

Vejamos abaixo um exemplo de código HTML inicial para protótipos de projetos em

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

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

Protótipos de Projetos Lumis Página 11

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

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

Algumas notas sobre o código acima:

A. Marcados em verde, estão os trechos de código que montam as caixas de teste,

Protótipos de Projetos Lumis Página 12

C. Marcados em vermelho, estão às classes que o Lumis insere automaticamente no

cEZTPageAreaX, cEZTPageAreaXColumnY (Classes Genéricas)

Estamos simplesmente replicando a estrutura que o Lumis monta automaticamente já

/assim você pode usar classes próprias para o projeto.../