O Less é um framework de escrita de css que permite utilizar variáveis, herança e outros coisas giras. Mencionei-o há uns posts atrás, linkando as versões de ruby e .net. As versões que mencionei são construídos server-side. Actualemnte, o Less está a ser portado para javascript, permitindo a mesma funcioanlidade mas processado do lado do cliente. Este post refere essa evolução:

http://fadeyev.net/2010/06/19/lessjs-will-obsolete-css/

Outro framework do género a ver: Sass http://sass-lang.com/

Ainda no outro dia, falava com os meus colegas de como seria muito bom que o CSS tivesse estruturas de herança incorporados e variáveis.. especialmente variáveis, para não ter de definir constantemente as mesmas coisas.

E hoje enquanto lia o blog do Spaanjaars, descubir o .Less, uma biblioteca dedicada a extender o CSS, introduzindo variáveis e esquemas de herança. Soa bem? Se soa!!

Com o .Less, podemos escrever codigo com variáveis:

@brand_color: #4D926F;
 
#header {
  color: @brand_color;
}
 
h2 {
  color: @brand_color;
}

Ou nestings de selectores:

#header {
    color: red;
    a {
       font-weight: bold;
       text-decoration: none;
    }
}

Ou misturas de elementos:

.rounded_corners(@radius: 5px) {
  -moz-border-radius: @radius;
  -webkit-border-radius: @radius;
  border-radius: @radius;
}
 
#header {
  .rounded_corners;
}
 
#footer {
  .rounded_corners(10px);
}

Lindo, né? Originalmente, o Less foi construído para o Ruby (é um gem para o Ruby), mas um grupo converteu-o para .Net, criando o .Less. E ainda bem! No .Net, funciona como um HTTPHandler. Os ficheiros de CSS são ficheiros .less que são transformados aquando do pedido da página. É também possível usar templates T4 para criar versões estáticas do CSS.

A experimentar!

Pois é, esta semana e a passada é a do frenesim das interfaces. Mas ainda bem. Resumindo, tive uma certa “infelicidade” em comprar os controlos da DevExpress. Ainda por cima comprei uma licença Enterprise. Não são de todo maus, mas na realidade conseguem ser bastante. Tipo, têm funcionalidade boa compactada no controlo, e o aspecto visual e funcionamento acaba por ser relativamente intuitivo para o utilizador final. O problema é a API (quer server quer cliente) que é demasiado complexo e muitas vezes nada intuitivo (o que me tem causado muiiiitoo tempo perdido e muitas dores de cabeça). A coisa que mais me chateia naquilo é o HTML que é renderizado… meu Deus.. TABELAS POR TODO O LADO!!! . Género, para desenhar um select box são necessárias mil tabelas encaixadas umas nas outras. É código feio, muito feio, e difícil depois de fazer o que quer que seja com Javascript e jQuery, porque simplesmente não sabes onde actuar (o menu da aplicação, renderizado no cliente, ocupava umas 1500 linhas de código – agora são 160, incluindo javascript, e consigo facilmente encontrar as coisas que preciso!). Os controlos tem todos uma API do lado cliente, mas até hoje ainda não percebi nada daquilo, e a documentação daquilo é fraquinho.

O bom é que o serviço de apoio é bom, e o CodeRush é um excelente produto, e esse recomendo sem dúvida. É um auxilio fantástico. Mas os controlos podem esquecer. A menos que o projecto seja muito simples, sem camadas e objectos e camadas e afins, (tipo o ui conectar-se à BD), aquilo acaba por dar muitas dores de cabeça. Mais fácil gerar código e fazer as interfaces à mão com HTML e controlos ASP.Net, e ainda combinar CSS com jQuery. é o que tenho feito ultimamente com o meu colaborador, e acredita, estou bem mais satisfeito, e acredito que tenho uma interface bem mais agradável e funcional. Caí um bocado no “hype” daquilo, e infelizmente, hoje ando a refazer interfaces e designs…

Portanto, agora, tenho criado umas interfaces bem mais limpas e bem mais funcionais. Ainda mantenho alguns dos controlos em locais em que não “estragam” nada e mantém funcionalidade válida. Mas onde possível e onde se justifica, estou a limpar. E como é claro, há uma série de coisas que estou a aprender às custas disso (e uma biblioteca de javascript com funcionalidade universal às interfaces, que tem sido muito útil).

Então uma revisão rápida às “coisas” aprendidas:

• É possível criar templates do lado cliente para renderizar dados vindos em chamadas AJAX. Tenho testado duas formas, com bons resultados em ambos, sendo mais ou menos útil numa ou noutra situação. Um á muito boa quando a resposta AJAX é uma lista. Neste caso é a solução do script do tipo “text/html” com o template de renderização em html, e os campos a preencher em entre tags <#= #> (semelhante ao T4). É depois usado uma função javascript para correr o template e substituir o os campos com o resultado do pedido AJAX. O método está descrito no blog do Dan Whalin e ainda no do Rick Strahl. Recomendo uns testes. É muito rápido na execução (a latência é reduzida por haver poucos dados na transmissão) e é óptimo para soluções de paginação.O segundo método é o de ter uma div escondida, com a estrutura de apresentação dos dados e os campos bem identificados, e usar o clone() do jquery, para criar uma cópia do bloco, preenche-lo, e apresentar no local onde necessitar. O clone é opcional e depende do que é pretendido, mas é uma solução muito útil para apresentar detalhe e blocos de inserção / edição. E é facil de implementar e perceber. Arisco dizer mais fácil que soluções compradas…Sério.
• JSON é fantástico. Dados bem estruturados e que ocupam muito pouco espaço. Muito menos que XML. Diria mais limpo, até. Mas não é um mar de rosas total. Por exemplo, a serialização de Datas é muito estranho, porque a data é em si uma estrutura de dados complicado de representar. Alías, no javascript, tens uma forma única que é através do construtor “new Date()”. Problema é que JSON é transmitida como texto e a deserialização dá barraca.Solução? O serviço .NET envia uma string do tipo “/Date(1241796300465)/” O numero no interior com 13 digitos, representa o numero de milisegundos desde 1 de Janeiro de 1970, até à data ali representada. para transformar isso, nada como um pouco de código Javascript:

  function GetJSDateFromNET(netDateString) {
     var myregexp = /\d{13}/;
     var match = myregexp.exec(netDateString);
     if (match != null) {
        result = match[0];
     } else {
        result = "";
     }
   
     var foo = new Date(parseInt(result));
     return foo;
  }

  Assim, procuro os 13 digitos via regex, e crio a data a partir do número no encontrado, que é efectivamente suportado pelo construtor de Datas do javascript. Também evito um eval que poderia ser de alguma forma perigosa, imagino.

• Prototypes. Muito bom! Melhora a escrita no javascript permitindo encadear funções de instâncias (métodos), e extender as funcionalidades de tipos basicos como strings, inteiros e datas. Já tinha visto, mas nunca tinha percebido ou notado o potencial. Agora, sim. Por exemplo, para a função anterior, já posso aplicar uma função directamente ao tipo string para criar a data, e se quiser, encadiar uma transformação para string formatada:

  msg.d.CampoDeDataDoJSON.toDateJsonNet().toYMDString();

  que resultaria numa string com o formato “yyyy-MM-dd”. Para isso tenho:

  String.prototype.toDateJsonNet = function() { return GetJSDateFromNET(this); }
   
  function DateToYMDString(date) {
      return date.getFullYear() + "-" + (date.getMonth() + 1).toString().lpad('0', 2) + "-" + date.getDate().toString().lpad('0', 2);
  }
   
  Date.prototype.toYMDString = function() { return DateToYMDString(this);}

  De uma forma simples, o prototype acrescenta funcionalidade ao tipo (aqui é com um tipo de dados base, mas podia ser um tipo que eu criei). Também te deixa o código mais limpo e legível, o que é sempre importante!

• display:inline-block. Esta é fantástica. E resolve um problema “clássico” de colunas, sem recorrer a tabelas nem floats. Tem algumas manhas, e dependências de browsers que aplicam incorrectamente (mais IE hacks, mas simples), e bem explicadas aqui, aqui, e aqui. Para o meu caso quero duas colunas, lado a lado, baseados em divs.

  <div class="col1">
  	...
  </div>
  <div class="col2">
  	...
  </div>

  .col1{width:70%; display:inline-block; vertical-align:top;*display:inline;*zoom:1}
  .col2{width:29%; display:inline-block; vertical-align:top;*display:inline;*zoom:1 }

  O segredo está na combinação “display:inline-block” com “vertical-align:top;” o primeiro permite colocar divs lado a lado, mas verticalmente ficam alinhados pela base do texto contido nas divs. para isso, serve o vertical-align:top. Isto funciona bem no FF3.5. Para resolver para IE8, basta o “hack” do asterisco como prefixo no display:inline e zoom:1, que são interpretados apenas pelo IE. Apenas testei no IE8 (que é o q necessitava) e resulta bem. O que mais gosto disto é que a div que suporta as duas colunas 8um género de contentor clássico para centrar tudo) cresce quando qualquer das duas colunas cresce, o que não acontece com as soluções de float, como tinha anteriormente. Esta fui uma bela revelação para mim, que já tive este problema diversas vezes!

E por hoje chega. Ficam assim aqui algumas das fantásticas revelações destas semanas!!!

O catálogo do Rockable aumentou. Depois do excelente e-book “How to be a Rockstar Freelancer“, os criadores do Freelance Switch, NetTuts e PSDtuts publicaram o novo “How to be a Rockstar Wordpress Designer“. Esta edição são 303 páginas, com layout, configuração e código. Incluí além do PDF, ficheiros de código PHP e ficheiros do photoshop. Custa $29 (€22) e é distribuído através do site E-junkies.

RockablePress.com

A Smashing Magazine tem um óptimo artigo sobre a estilização de tabelas com CSS. Realmente, uma tabela estilizada torna-se mais legivel e util na leitura de dados, quando efectuado correctamente. O artigo apresenta os 10 esquemas mais funcionais, com pros e contras.. A ver!

http://www.smashingmagazine.com/2008/08/13/top-10-css-table-designs/

Uma questão comum que surge com GridViews é ter a possibilidade de mostrar ou esconder colunas aquando da impressão. Uma forma simples de resolver a questão é utilizar uma stylesheet de impressão, aplicada sempre que o browser recebe o comando de impressão e que inclui uma classe do género:

.noprint{display:none;}

Todos os elementos que tiverem esta classe atribuída poderão ser visíveis no ecrã, mas na impressão desaparecerão.

No caso da GridView, se tivermos uma coluna (TemplateField) com botões, por exemplo, e não quisermos que os botões sejam visíveis, basta no TemplateField definir HeaderStyle-CssClass e ItemStyle-CssClass con a classe “noprint”

<asp:TemplateField (...) HeaderStyle-CssClass="noprint" ItemStyle-CssClass="noprint">
   <ItemTemplate>
	(...)
   </ItemTemplate>
</asp:TemplateField>

Só definir o ItemStyle-CssClass elimina os botões, mas preserva a coluna. Atribuindo a classe a ambos esconde a coluna. Se houver um Footer, será necessário efectuar o mesmo para o FooterStyle-CssClass.

Uma das coisas mais ‘chatas’ de trabalhar CSS é conseguir colocar tudo no devido lugar. Design baseado em standards e boas práticas pedem o uso de CSS para produzir os layouts, e não tabelas – tabelas são para dados!

Infelizmente, o CSS nem sempre é amigável, especialmente no que diz respeito a estruturas com posicionamentos complexos ou multicolunas. Algo que parece ou devia ser simples nem sempre é. Alias há variadíssimos artigos acerca daquilo que alguns até chamam do Santo Grael dos layouts – o de 3 colunas, apenas baseado em CSS. Algo para o Indy descobrir?

Felizmente, tem surgido alguns frameworks que podem ajudar na tarefa de produzir layouts complexos e consistentes, especialmente se o conceito de grelha seja aplicável. O framework é, essencialmente, um conjunto de ficheiros .css que primeiro “limpam” os estilos que os browsers colocam (uniformizando) e depois disponibilizam uma serie de classes com características predefinidas para utilizar na construção da grelha, como por exemplo a definição das várias dimensões de colunas, ou a definição de uma coluna “no fim duma linha”, etc… As classes existem, só temos de aplicar ao nosso gosto e conveniência. Muito tempo poupado … muito tempo!

O BlueprintCSS é um dos mais populares existentes e é bastante flexível, aparentemente. Estou a pensar usar este no layout a criar no blog, quer para aprender, quer para testar. Já utilizei o 960 Grid System uma vez noutro projecto e simplificou em muito o processo de construção. Infelizmente o 960 grid não é de todo flexível, mas serve na perfeição para layouts que encaixam no perfil de 12 ou 16 colunas com 960px de largura no total.

No caso do Blueprint, há ficheiros de reinicialização, a grelha, tipografia, formulários, impressão e ainda os hacks para os ie(s). Se se não basta, há uma série de ferramentas já disponíveis para ajudar a manipular a grelha – o Blueprint Grid CSS Generator – ou documentos com guias (Blueprint CSS Cheatsheet).

Vou ver se resulta