Prottipos de Projetos Lumis

  • Published on
    10-Jun-2015

  • View
    2.481

  • Download
    1

DESCRIPTION

Estou disponibilizando esses guias para que possam ser facilmente acessados de qualquer lugar. As verses oficiais (da Lumis) podem estar mais atualizadas que essas.

Transcript

Tutorial:

Prottipos de Projetos Lumis

Este documento visa expor uma metodologia especfica para a criao de prottipos 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 prottipos HTML prontos para serem usados no Lumis, com o mnimo ajuste de cdigo possvel. Na medida em que mais e mais desenvolvedores Lumis aderirem a essa metodologia, ficar mais simples o intercmbio de conhecimento (por exemplo, atravs do Lumis Information Exchange, o LINX: http://linx.lumis.com.br) e as manutenes posteriores ao lanamento dos projetos.

1. Interfaces de servioNo Lumis entendemos por interface de servio o resultado visual final que monta uma dada interface. Como em HTML s podemos montar estruturas em caixas (sejam elas em , , , , etc.), a grande maioria das interfaces de servio montar visualmente uma caixa. E como o cdigo HTML lido de cima para baixo, a ponta superior esquerda da caixa corresponder ao incio do cdigo de uma interface, e a ponta inferior direita corresponder ao final do cdigo de uma interface. Talvez o entendimento fique mais simples visualizando a imagem abaixo:

Imagem 1.1: Esta inferface de um servio de destaque da Pgina Inicial do R7.com um bom exemplo compatvel com a maior parte das interfaces de servios Lumis. O cdigo 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 cdigo gerado dentro de uma interface de servio, atravs da edio de seu XSL, em nosso prottipo HTML devemos apenas ter o cuidado de demarcar onde comea o cdigo de cada interface, de preferncia com comentrios no estilo incio/fim ou abre interface/fecha interface. Por exemplo: Minha logomarca Ou mesmo: Minha logomarca Nesse sentido, o mais importante j ter ao incio da criao do prottipo HTML um wireframe bem definido sobre como sero montadas as interfaces de servios do projeto: quais sero cdigo HTML esttico (podendo ser montadas simplesmente em servios HTML no Lumis), quais sero servios padro do Lumis (como Barra de Navegao, Matrias, Enquete, etc.), quais sero servios customizados para o projeto (como aquele destaque para o R7, na imagem 1.1), e quais chamaro integrao por iframes, flash, applets, etc. (estes geralmente podem ser apenas imagens de marcao no HTML de prottipo).

Prottipos de Projetos Lumis

Pgina 2

1.1 Interfaces de servio complexas Interfaces de servio complexas geralmente trazem uma interface dentro da outra, de maneira que o cdigo HTML do prottipo precisa j ser montado considerando essas limitaes. Uma interface precisa ser montada dentro de outra sempre que ela precisa aparecer entre o incio e o fim do cdigo de outra interface. Nesse caso o entendimento fica bem mais simples se visualizarmos atravs de imagens:

Imagem 1.2: Muitas vezes, por razes tcnicas, precisamos montar um prottipo HTML que considere interfaces complexas, quando uma interface precisa vir montada dentro da outra. sempre recomendvel j prever todas essas situaes ainda no wireframe, de modo que o prottipo HTML j as levar em considerao. A soluo, 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 ttulo, e traria um sem borda abaixo. O segundo bloco viria somente aps o fim da interface de Texto Simples, e montaria o calendrio dentro de um sem borda acima. Se o primeiro bloco no tiver contedo cadastrvel (ou seja, se o ttulo Agenda do Dia puder ser escrito hard-coded diretamente no cdigo), ele poder at mesmo ser montado por uma interface de servio HTML no Lumis. Se, no entanto, o contedo precisar ser cadastrvel (ou seja, contedo dinmico), no teremos como evitar o uso de 2 XSLs para montar os dois blocos da interface. preciso levar em considerao que a mesma interface visual que vemos na imagem, ser montada por duas interfaces de servios distintas no Lumis, correspondendo a cada bloco que mencionamos acima. O ideal nesses casos que o cdigo HTML do prottipo seja bem comentado, explicando a necessidade de separao da interface em blocos:

Prottipos de Projetos Lumis

Pgina 3

Agenda do Dia Lula inaugura hoje sindicato em So Paulo Repare que esse tipo de situao tambm tem impacto na forma como montado o CSS do projeto. Seria intil ter uma classe que montasse toda a caixa de Agenda do Dia como um nico , por mais que esta fosse a melhor forma de montar, visto que nesse caso no temos como passar por cima de uma limitao de arquitetura do projeto. Ento, a melhor soluo montar logo 3 classes distintas: agenda_bloco1 para o topo, agenda_texto para a interface de texto simples, e agenda_bloco2 para o calendrio. 1.2 Teleporte de HTML Alguns casos so to complexos que no admitem sequer a soluo dada acima (1.1), de separar a interface em blocos. Nesses casos a nica soluo o uso do procedimento de teleporte de HTML, que no final das contas no algo to 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 escondido em outro visvel, que est sendo chamado em outro local do cdigo. Ele tambm pode ser usado para montar certos layouts "impossveis" no LPS, quando o uso de colspan e/ou rowspan no suficiente para resolver o problema (falaremos sobre isso mais adiante). Vejamos um exemplo: A caixa logo abaixo... ...deveria vir abaixo desta linha, mas o script de innerHTML a "teleportou" para cima.

Prottipos de Projetos Lumis

Pgina 4

Link if(document.getElementById("showSource")) { document.getElementById("showSource").innerHTML=document.ge tElementById("source").innerHTML; } No exemplo acima, todo o cdigo dentro do com ID "source" e escondido atravs de CSS (style="display:none;") chamado, como uma cpia, no outro com ID "showSource", e que est visvel. A vantagem desse tipo de procedimento que o 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 pgina, deixamos ela escondida com CSS, e chamamos o seu cdigo dentro do XSL de outra interface. Usando esse procedimento, praticamente qualquer layout pode ser montado com o Lumis. *** Uma variao desse cdigo leva em considerao a questo de ele s funcionar com o JavaScript do browser habilitado. Neste caso, melhor no esconder o de ID "source" usando CSS, e sim JavaScript - dessa forma, com o JavaScript do browser desabilitado, a interface no ser teleportada, mas da mesma forma no ser escondida, o que possibilitar ainda alguma forma de interao e navegao no site, mesmo que no seja a ideal. Vejamos o cdigo: A caixa logo abaixo... ...deveria vir abaixo desta linha, mas o script de innerHTML o "teleportou" para cima. Link

Prottipos de Projetos Lumis

Pgina 5

if(document.getElementById("showSource")) { document.getElementById("source").style.display="none"; document.getElementById("showSource").innerHTML=document.getElem entById("source").innerHTML; } Voc precisa ter o JavaScript habilitado no browser para ter uma visualizao ideal desta pgina. Caso o teleporte de HTML seja definido como soluo final ainda no wireframe ou na construo do prottipo HTML do projeto, o ideal deixar o cdigo j montado com os s e seus respectivos IDs, assim como os scripts de teleporte Tudo o que pode ser montado e testado ainda no prottipo HTML prefervel a opo de descobrir os erros somente quando j estamos montando o projeto no Lumis, mexendo com montagem e XSLs de servios.

Prottipos de Projetos Lumis

Pgina 6

2. Estrutura de arquivosUm dos objetivos de se criar prottipos em HTML para projetos Lumis tambm j deixar os arquivos estticos css, javascript, flash, etc. organizados em estruturas de pastas que sero as mesmas utilizadas no servidor final. Dessa forma, chamadas para arquivos como, por exemplo, nas tags de imagem (), j chamaro as imagens no caminho correto, e quando o desenvolvedor for criar os XSLs a partir desses HTMLs de prottipo, no precisar se preocupar em converter os caminhos um por um. No entanto, essa ser apenas nossa sugesto para a organizao de arquivos. Muitas empresas tm um procedimento especfico para a criao de estruturas de arquivos e suas nomenclaturas. Se no for possvel seguir nossa sugesto, de qualquer forma ainda muito importante que sigam, em seu prottipo HTML, a mesma estrutura que usaro 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 prottipo devem ficar nessa mesma pasta, e a partir dela criaremos uma outra pasta com um nome abreviado do projeto, podendo mesmo ser um acrnimo (ex: um projeto para uma seguradora chamada Big Bird Seguros poderia usar o acrnimo 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 sugestes 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 mdia, incluindo vdeos e aplicativos os mais comuns so os arquivos .swf (ShockWave/Flash)

Prottipos de Projetos Lumis

Pgina 7

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 mdia no prottipo HTML para um projeto em LPS. A pasta release a pasta root, onde temos o main.asp o arquivo home.html apenas um dos inmeros HTMLs que podero ser montados para este prottipo, e todos eles precisam ficar na mesma pasta release. Repare que na imagem acima escolhemos um nome genrico para a pasta do projeto: project. este nome que precisa ser ajustado para refletir o nome do seu projeto (de preferncia abreviando nomes grandes). Nos HTMLs de prottipo, assim que chamaremos, por exemplo, uma imagem intitulada image.gif: J um arquivo css intitulado project.css seria chamado da seguinte forma nos HTMLs de prottipo:

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 prottipo devem ficar nessa mesma pasta, e a partir dela criaremos uma outra pasta com um nome abreviado do projeto, podendo mesmo ser um acrnimo (ex: um projeto para uma seguradora chamada Big Bird Seguros poderia usar o acrnimo 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 sugestes 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)

Prottipos de Projetos Lumis

Pgina 8

D. Na pasta media incluiremos os arquivos de mdia, incluindo vdeos e aplicativos os mais comuns so 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 mdia no prottipo HTML para um projeto em LPJ. A pasta www a pasta root, onde temos o main.jsp o arquivo home.html apenas um dos inmeros HTMLs que podero ser montados para este prottipo, e todos eles precisam ficar na mesma pasta www. Repare que na imagem acima escolhemos um nome genrico para a pasta do projeto: project. este nome que precisa ser ajustado para refletir o nome do seu projeto (de preferncia abreviando nomes grandes). Nos HTMLs de prottipo, assim que chamaremos, por exemplo, uma imagem intitulada image.gif: J um arquivo css intitulado project.css seria chamado da seguinte forma nos HTMLs de prottipo:

Prottipos de Projetos Lumis

Pgina 9

3. Regras de XHTMLTodo HTML criado no prottipo deve ser compatvel com as exigncias do XHTML, pois assim ele tambm ser compatvel com o XSL. Abaixo inclumos resumidamente as regras para se escrever cdigo XHTML vlido: A. Todas as tags devem ser fechadas. Ou seja, se voc usar um ter de fech-lo sempre com um ou o arquivo ficar incorreto. Lembramos tambm que mesmo tags que no costumam abrir e fechar tem de ser fechadas. Isso ocorre com o
por exemplo, que deve ser usado como
, ou sua forma abreviada
B. Todas as tags devem ser abertas e fechadas respeitando sua ordenao. Ou seja, se voc quer envolver um texto com as tags e por exemplo, deve fazer dessa forma: Texto. Caso faa em outra ordem, o arquivo ficar incorreto, como por exemplo: Texto (Note que aqui o foi fechado antes do , da o erro). C. Todas as tags devem ser escritas em caixa baixa. Ou seja, ir funcionar, enquanto ou deixar o arquivo incorreto. D. Todas os atributos de uma tag devem vir entre aspas duplas. Ou seja, ir funcionar, enquanto deixar o arquivo incorreto. E. Deveremos usar cdigos especficos para caracteres especiais. Aqui ocorre um problema mais grave, pois muitos esto acostumados com os cdigos de caracteres especiais do HTML, como o para representar espao em branco. No XSL no ir funcionar, e devemos usar no lugar. Felizmente temos bastante material disponvel sobre isso na web, recomendamos este como referncia rpida: http://www.cssplay.co.uk/menu/code.html 3.1 Validao de XHTML Aps terminar alguns trechos de seus HTMLs, recomendvel ir validando online para verificar se no existe algum erro de XHTML: http://validator.w3.org/ Alguns programas de edio de cdigo podem vir com validadores XHTML embutidos, o que pode facilitar o processo.Prottipos de Projetos LumisPgina 104. HTML de prottipoEsta a parte mais importante deste tutorial, pois trar informaes detalhadas sobre como montar seu HTML de prottipo. Os cdigos aqui utilizados podem servir de base para o incio do trabalho, poupando tempo. A funo principal desses cdigos prever o HTML que o Lumis insere automaticamente em torno das interfaces de servio em uma pgina. A menos que voc use o Lumis Portal Java com Template Files, no ter controle total sobre esse HTML e, portanto, seu prottipo precisar replicar o que o Lumis monta automaticamente. Na realidade o Lumis monta muito mais cdigo do que o exposto nos exemplos abaixo, porm estamos focando apenas no cdigo mnimo, ou seja, aqueles trechos de HTML que realmente iro influenciar a estrutura da visualizao final. Por exemplo, em torno de cada interface no LPS e no LPJ em modo de layout Com Tabelas, so montadas novas tabelas dentro das j existentes, e que so consideradas em nossos exemplos abaixo; Porm, essas tabelas no interferem em nada na estrutura final do layout, por isso optamos por ignor-las, juntamente com todo o cdigo adicional que no influi no resultado final dentro do Lumis. 4.1 HTML de prottipo para o Lumis Portal Suite O LPS no possui modo de layout Sem Tabelas, como no LPJ; Portanto, qualquer projeto feito nele no poder ser Tableless, j que o Lumis montar automaticamente tabelas em torno das interfaces de servio inseridas nas pginas. Vejamos abaixo um exemplo de cdigo HTML inicial para prottipos de projetos em LPS: Lumis Project div.box {background:#f9f9f9;border:1px solid #ccc;padding:5px;} Prottipos de Projetos LumisPgina 11 HTML para primeira interface Lumis (ex: interface html montando cabealho). HTML para segunda interface Lumis (ex: barra de navegao). HTML para terceira interface Lumis (ex: lista de notcias). Algumas notas sobre o cdigo acima: A. Marcados em verde, esto os trechos de cdigo que montam as caixas de teste, somente para que possa ser visualizado o espao que cada interface ir ocupar. Tanto o estilo aplicado dentro da tag dentro do quanto os cdigos que montam os podem ser deletados assim que comear a trabalhar usando este cdigo como base inicial.Prottipos de Projetos LumisPgina 12B. Repare que o DOCTYPE est configurado para XHTML Transitional, se quiser usar XHTML Strict em seu projeto, recomendvel que mude j no prottipo HTML, pois algumas inconsistncias podem aparecer quando mudar de um DOCTYPE para o outro. C. Marcados em vermelho, esto s classes que o Lumis insere automaticamente no cdigo final. Elas so: cEZTBody Esta classe serve para que possamos aplicar layout css na tag . No possvel adicionar outra classe nesta tag, nem utilizar outro ttulo de classe, pois o LPS no permite. cEZTPage Esta classe serve para que possamos aplicar layout css na tag em torno de toda a estrutura, ou seja: imediatamente aps a tag . Normalmente utilizado para centralizar o layout por css, embora possa servir tambm para aplicar bordas e espaamentos globais. No possvel adicionar outra classe nesta tag, nem utilizar outro ttulo de classe, pois o LPS no permite. cEZTPageAreaX, cEZTPageAreaXColumnY (Classes Genricas) Essas classes so inseridas automaticamente nas tabelas estruturais de acordo com a adio de reas e colunas na pgina, dentro do Lumis. Falaremos sobre essas Classes Genricas mais adiante... *** Finalmente, podemos falar sobre a lgica exposta no cdigo. 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 prottipo. Cada rea monta uma tabela e, dentro de uma rea, ao adicionarmos novas interfaces uma ao lado da outra, novas colunas sero montadas. Dentro de uma coluna, contanto que insiramos uma interface abaixo da outra, podemos ter virtualmente quantas interfaces diferentes quisermos. Porm, quando as interfaces precisam vir uma ao lado da outra, teremos de prever a criao de novas clulas de tabela em nosso prottipo. Uma questo bastante importante a marcao da largura de cada coluna, pois se estourarmos as larguras, o layout poder quebrar. Outro detalhe que essas larguras precisaro ser inseridas na edio de pginas e templates de pginas no Lumis, com o valor exatamente igual ao do prottipo. Recomendamos que, ainda desde o layout final (em .psd ou .png) essas larguras j estejam delimitadas e anotadas, assim o trabalho de criar o prottipo HTML ficar mais simples. Em nosso exemplo acima, a largura total do site de 770 pixels. A primeira rea, com o cabealho, tem apenas uma nica coluna e, portanto, tambm 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.Prottipos de Projetos LumisPgina 134.1.1 Classes Genricas no Lumis Portal Suite O Lumis Portal Suite disponibiliza classes genricas que podem ser aplicados no layout que criado automaticamente pelo portal. Toda vez que criamos uma nova pgina no LPS, uma estrutura genrica de HTML automaticamente criada pelo Lumis para mostrar as interfaces inclusas na pgina. O Lumis cria um esqueleto que monta o cdigo entre as interfaces usando algumas tabelas. A boa notcia que cada linha e clula dessas tabelas tm uma classe especfica. A essas classes demos o ttulo de Classes Genricas. Veja abaixo um diagrama que mostra a lgica pela qual essas classes so inclusas no cdigo HTML final:Imagem 4.1: Diagrama que demonstra a lgica de nomenclatura das Classes Genricas. A primeira rea (ou tabela) trar a classe cEZTPageArea0 em sua tag , a segunda cEZTPageArea1, a terceira cEZTPageArea2, e assim por diante; Seguindo uma lgica parecida, cada coluna de uma rea trar classes em suas tags , comeando por cEZTPageAreaXColumn0 e prosseguindo cEZTPageAreaXColumn1, cEZTPageAreaXColumn2, e assim por diante onde X corresponde ao nmero da rea em que a coluna est localizada. Geralmente usamos algumas Classes Genricas para incluir um background ao longo de vrias interfaces sem ter de editar uma por uma. Por exemplo, caso quisssemos que todo cabealho de pgina tivesse fundo cinza, bastaria incluir esse cdigo em nosso arquivo CSS:Prottipos de Projetos LumisPgina 14.cEZTPageArea0 { background:#f5f5f5; } As Classes Genricas nem sempre se fazem necessrias, mas podem salvar bastante trabalho na edio de um portal. Sempre tenha em mente que elas existem, apesar de no aparecerem em css nenhum nem mesmo no webportal.css, padro do Lumis. Nota: Usando JQuery, possvel aplicar estilos as reas () e colunas () montadas automaticamente pelo Lumis em torno das interfaces. Para tal voc precisar apenas de uma interface HTML que traga um marcador atravs do ID de um , por exemplo: Atravs desse marcador, e com algum conhecimento de JQuery, possvel encontrar a tag imediatamente anterior a este (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 mtodo o layout das pginas ficar menos preso, e voc poder futuramente adicionar novas reas entre as reas j existentes, sem precisar se preocupar em alterar a numerao de suas Classes Genricas (na verdade, nem precisar mais utiliz-las). 4.2 HTML de prottipo para o Lumis Portal Java No LPJ, nosso HTML de prottipo dever ser criado de acordo com o tipo de layout que ser utilizado para as respectivas pginas no Lumis: Com Tabelas ou Sem Tabelas (o que permite portais Tableless). Tambm existe a possibilidade do uso de Template Files, o que permite um controle total do cdigo HTML gerado, que deixaremos para falar no final deste tutorial. 4.2.1 Layout Com Tabelas Vejamos abaixo um exemplo de cdigo HTML inicial para prottipos de projetos em LPJ no layout Com Tabelas: Lumis Project div.box {background:#f9f9f9;border:1px solid #ccc;padding:5px;} Prottipos de Projetos LumisPgina 15 HTML para primeira interface Lumis (ex: interface html montando cabealho). HTML para segunda interface Lumis (ex: barra de navegao). HTML para terceira interface Lumis (ex: lista de notcias). Algumas notas sobre o cdigo acima: A. Marcados em verde, esto os trechos de cdigo que montam as caixas de teste, somente para que possa ser visualizado o espao que cada interface ir ocupar. Tanto o estilo aplicado dentro da tag dentro do quanto os cdigos que montam os podem ser deletados assim que comear a trabalhar usando este cdigo como base inicial.Prottipos de Projetos LumisPgina 16B. Repare que o DOCTYPE est configurado para XHTML Transitional, se quiser usar XHTML Strict em seu projeto, recomendvel que mude j no prottipo HTML, pois algumas inconsistncias podem aparecer quando mudar de um DOCTYPE para o outro. C. Marcados em vermelho, esto s classes que o Lumis insere automaticamente no cdigo final. Elas so: cLumBody Esta classe serve para que possamos aplicar layout css na tag . No possvel adicionar outra classe nesta tag, nem utilizar outro ttulo de classe, pois o LPS no permite. cLumPage Esta classe serve para que possamos aplicar layout css na tag em torno de toda a estrutura, ou seja: imediatamente aps a tag . Normalmente utilizado para centralizar o layout por css, embora possa servir tambm para aplicar bordas e espaamentos globais. No possvel adicionar outra classe nesta tag, nem utilizar outro ttulo de classe, pois o LPS no permite. areaclass, columnclass (Classes Livres) Essas classes so 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 ttulo dessas classes livre, o montador quem ir escolher. Normalmente essas classes so usadas para aplicar layouts de background ou padding (espaamento) a todas as interfaces dentro de uma mesma rea ou coluna mas atravs do uso de IDs tambm podem servir como marcao para eventos de JavaScript. *** Finalmente, podemos falar sobre a lgica exposta no cdigo. 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 prottipo. Cada rea monta uma tabela e, dentro de uma rea, ao adicionarmos novas interfaces uma ao lado da outra, novas colunas sero montadas. Dentro de uma coluna, contanto que insiramos uma interface abaixo da outra, podemos ter virtualmente quantas interfaces diferentes quisermos. Porm, quando as interfaces precisam vir uma ao lado da outra, teremos de prever a criao de novas clulas de tabela em nosso prottipo. Uma questo bastante importante a marcao da largura de cada coluna, pois se estourarmos as larguras, o layout poder quebrar. Outro detalhe que essas larguras precisaro ser inseridas na edio de pginas e templates de pginas no Lumis, com o valor exatamente igual ao do prottipo. Recomendamos que, ainda desde o layout final (em .psd ou .png) essas larguras j estejam delimitadas e anotadas, assim o trabalho de criar o prottipo HTML ficar mais simples. Em nosso exemplo acima, a largura total do site de 770 pixels. A primeira rea, com o cabealho, tem apenas uma nica coluna e, portanto, tambm tem 770 pixels. J a segunda rea (ou segunda tabela) vem com duas colunas: a coluna do MENU tem 190Prottipos de Projetos LumisPgina 17pixels 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 experincia 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 compreenso do que diremos abaixo. Vejamos abaixo um exemplo de cdigo HTML inicial para prottipos de projetos em LPJ no layout Sem Tabelas: Lumis Project div.box {background:#f9f9f9;border:1px solid #ccc;padding:5px;} /*isso pode ser usado para anular classes automticas aplicadas ao cdigo final*/ div.cLumArea, div.cLumColumn {float:none;} br.cLumAreaSeparator, br.cLumRowSeparator {clear:none;display:none;} /*assim voc pode usar classes prprias para o projeto...*/ div.columnclass {float:left;} class="box">HTML para primeira interface html montando cabealho). /HEADER -->
Prottipos de Projetos LumisPgina 18 HTML para segunda interface Lumis (ex:barra de navegao). HTML para terceira interface Lumis (ex:lista de notcias).
Algumas notas sobre o cdigo acima: A. Marcados em verde, esto os trechos de cdigo que montam as caixas de teste, somente para que possa ser visualizado o espao que cada interface ir ocupar. Tanto o estilo aplicado dentro da tag dentro do quanto os cdigos que montam os podem ser deletados assim que comear a trabalhar usando este cdigo como base inicial. B. Repare que o DOCTYPE est configurado para XHTML Transitional, se quiser usar XHTML Strict em seu projeto, recomendvel que mude j no prottipo HTML, pois algumas inconsistncias podem aparecer quando mudar de um DOCTYPE para o outro. C. Marcados em vermelho, esto s classes que o Lumis insere automaticamente no cdigo final. Elas so: cLumBody Esta classe serve para que possamos aplicar layout css na tag . No possvel adicionar outra classe nesta tag, nem utilizar outro ttulo de classe, pois o LPS no permite. cLumPage Esta classe serve para que possamos aplicar layout css na tag em torno de toda a estrutura, ou seja: imediatamente aps a tag . Normalmente utilizado para centralizar o layout por css, embora possa servir tambm para aplicar bordas e espaamentos globais. No possvel adicionar outra classe nesta tag, nem utilizar outro ttulo de classe, pois o LPS no permite. cLumArea Esta classe inserida automaticamente em todo que monta uma rea no Lumis. Este o correspondente do montado para cada rea no layout ComProttipos de Projetos LumisPgina 19Tabelas. Esta classe vem com o atributo float:left; aplicado pelo css padro do LPJ (portal.css), caso queira anular o float, use em seu css: div.cLumArea {float:none;}cLumColumn Esta classe inserida automaticamente em todo que monta uma coluna no Lumis. Este o correspondente do montado para cada coluna no layout Com Tabelas. Esta classe vem com o atributo float:left; aplicado pelo css padro do LPJ (portal.css), caso queira anular o float, use em seu css: div.cLumColumn {float:none;} cLumAreaSeparator Esta classe aplicada em tags
ao final de cada montado automaticamente a medida que adicionamos reas novas a pgina pela edio dentro do Lumis. Esta class vem com o atributo cler:both; aplicado pelo css padro do LPJ (portal.css), e serve para dar clear nos floats das tags montando colunas acima. Caso queira anular o clear, use em seu css: br.cLumAreaSeparator {clear:none;} Porm, o mais recomendado simplesmente no mostrar essas tags
, evitando causar espaamentos indevidos entre as interfaces de servio: br.cLumAreaSeparator, br.cLumRowSeparator {clear:none;display:none;} Repare que o cdigo acima precisa ser utilizado ainda que voc no aplique o css padro do LPJ em seu projeto, j que as tags
so montadas automaticamente pelo Lumis. No HTML de exemplo acima no inclumos as tags
com classe cLumRowSeparator porque elas no interferem na visualizao final do layout. Se quiser sumir com essas tags
, entretanto, recomendamos que aplique o display:none; logo em ambas, conforme o trecho de css logo acima. areaclass, columnclass (Classes Livres) Essas classes so 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 ttulo dessas classes livre, o montador quem ir escolher. Normalmente essas classes so usadas para aplicar layouts de background ou padding (espaamento) a todas as interfaces dentro de uma mesma rea ou coluna mas atravs do uso de IDs tambm podem servir como marcao para eventos de JavaScript. D. Marcados em roxo, esto os trechos de css sugeridos para que anulemos os atributos vindos do css padro do LPJ (portal.css), assim como fazer sumir as tags
montadas automaticamente pelo Lumis, e que talvez causem espaamentos desnecessrios. exatamente sobre isso que falamos logo acima na letra C. *** Finalmente, podemos falar sobre a lgica exposta no cdigo. A verso de layout Sem Tabelas do LPJ tenta simular o layout criado com tabelas inserindo floats atravs de classes css (float:left;). Basicamente toda rea monta um com classe cLumArea, e toda coluna monta um outro com classe cLumColumn dentro do da rea.Prottipos de Projetos LumisPgina 20Aps o trmino de cada rea o Lumis insere automaticamente o
para dar clear nesses floats. Isso at funciona bem para layouts bsicos, mas dificilmente vai abranger layouts um pouco mais complexos. Nesses casos, sugerimos que as classes vindas do css padro do LPJ sejam anuladas (ver letras C e D acima), ou preferivelmente que o css padro sequer seja aplicado no projeto (ainda assim preciso sumir com as tags
de separao). Felizmente, o LPJ permite que apliquemos nossas prprias classes as reas e colunas. Isso significa que toda interface de servio poder ter at duas tags com classes especficas em torno uma para coluna e outra para a rea , porm no mais do que isso. Ainda assim, a maior parte dos layouts poder ser montada sem problemas. Se por alguma razo precisar ter mais de duas tags com classes especficas em torno de uma nica interface de servio, sugerimos usar o teleporte de HTML descrito em 1.2, ou usar Template Files para ter controle total do cdigo gerado em torno das interfaces (ainda falaremos sobre eles a seguir). 4.3 Sobre o evento de onLoad na tag Outra questo importante a ser considerada no prottipo HTML e isto vale tanto para cdigos formulados para o LPS quanto para o LPJ nunca usar o evento de onLoad da tag , ou seja, o . Isto porque o Lumis precisa deste evento para que os scripts padro do produto rodem normalmente. Eles so vitais para o correto funcionamento da edio F12, assim como diversas funcionalidades padro de certos servios. Caso precise usar este evento de qualquer maneira em seu projeto, recomendamos entrar em contato com o suporte da Lumis. Antes, porm, verifique se no existem outras possibilidades por exemplo, muitos menus drop-down usam o evento de onLoad no para funcionar. Isso, no entanto, pode facilmente ser contornado se inserirmos o mesmo script em uma tag que esteja em torno do menu, porm usando o evento de onMouseOver no lugar de onLoad. Como todo menu drop-down depende de onMouseOver para iniciar a animao do drop-down, no h problema na transferncia.Prottipos de Projetos LumisPgina 215. Template FilesNo Lumis Portal Java, a partir das verses lanadas no final de 2009 em diante, passamos a poder utilizar Template Files em projetos no Lumis. Os Template Files so arquivos .html aplicados a pginas do Lumis que substituem a gerao automtica de HTML do Lumis em torno das interfaces, colunas e reas. Eles representam uma customizao completa de layout no produto, deixando o HTML praticamente 100% livre para edio. A lgica dos Template Files simples: eles montam uma pgina .html comum, podendo inclusive ser gerados diretamente a partir dos HTMLs originais dos prottipos de projetos. Onde temos o HTML hard-coded, no-dinmico, montando o layout das interfaces de servio, bastar substituir o bloco de cdigo que monta a interface correspondente por uma chamada especfica para um ID (identificador nico). Na edio da pgina ou template de pgina do Lumis, editaremos uma coluna de modo a inserir este mesmo ID, e todas as interfaces de servio inseridas na coluna entraro no cdigo final exatamente onde est a chamada para este ID. Isso significa tambm que, para projetos onde usamos Template Files, apenas essas regras se aplicam para a criao do HTML de prottipo: A. Conforme dito em 4.3, continua sendo proibido utilizar o evento de onLoad da tag B. Conforme dito ao longo do captulo 1, preciso demarcar corretamente o incio e fim do cdigo HTML para cada interface de servio, montando o css de acordo e, principalmente, levando em considerao as interfaces complexas (ver 1.1) existentes no wireframe. *** Certamente, so bem menos regras a serem consideradas. Porm, o uso de Template Files requer maior conhecimento de HTML e css da parte dos montadores no Lumis, de modo que no ir adiantar muito facilitar a criao de prottipos HTML pelo uso de Template Files, se na hora de passar o prottipo para o Lumis os montadores tiverem dificuldades em lidar com os Template Files.Prottipos de Projetos LumisPgina 226. Porque criar prottipos HTML para projetos LumisAlm dos motivos bvios que levam todos os desenvolvedores a montar prottipos HTML para seus projetos web, a prtica 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 lgica de trabalho quando estamos desenvolvendo HTML e css bem distinta da lgica de montagem dentro do Lumis. Na primeira, estaremos mais preocupados em criar cdigo 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 pginas, instanciar servios e criar as respectivas administraes, criar XSLs com chamadas dinmicas a partir do cdigo HTML esttico do prottipo, verificar controle de acesso de usurios, se todos os formulrios esto funcionais, etc. Ou seja, so lgicas e procedimentos de trabalho suficientemente distintos para que, ainda que sejam os mesmos desenvolvedores a cuidar tanto do HTML do prottipo quanto da montagem no Lumis, valha a pena fazer uma coisa de cada vez, evitando confuso e re-trabalho desnecessrios. Sabemos que muitas vezes os prazos curtos impediro 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 considerao quais servios Lumis sero usados em cada bloco de layout, at um prottipo HTML previamente ajustado para o Lumis, sero sempre bem vindos, e nunca um tempo gasto desnecessariamente. Boa sorte!Prottipos de Projetos LumisPgina 23