Com o "surgimento" do "conceito" de Web 2.0, nasceu uma corrida entre as comunidades de desenvolvedores web (sejam elas PHP, Java ou .NET) para a adequação dos sistemas correntes para as diretrizes defendidas pelo "movimento web 2.0".
Conceitos que apesar de nem serem tão novos, nunca tinham caído no agrado nem dos próprios profissionais e nem dos próprios arquitetos de frameworks sejam eles da Microsoft ou não.
A preocupação sempre foi com "o que" está "por trás" do que se vê no site e não na apresentação em si.
O layout ou design até que sempre foi focado para tipo de internauta que estava a acessar o site, porém a qualidade que a informação era (é) oferecida nem sempre permitia (permite) uma boa assimilação de quem está acessando.
A existência de Frameworks sempre foi facilitar o desenvolvimento no sentido de diminuir a replicação de código pela componentização, deixando mais produtiva a arte da programção.
Essa produtividade ainda é melhorada quando dispomos de ambientes de desenvolvimento que sem dúvida, além de tornar o nosso trabalho mais fácil o torna mais rápido e desafiador, pois agora temos mais tempo para focar no ítem principal do sistema, ao invés de detalhes secundários.
O ASP.NET nasceu deixando pra trás aquela programação "amarrada" (código + HTML) que o ASP 3.0 utilizava. Nasceu trazendo a idéia de componentes e seus eventos que já existia no Desenvolvido para Aplicativos Desktop. Porém, quando se fala na apresentação desses componentes, algumas vezes podemos compará-los àquele tipo de programação antiga do ASP 3.0.
Por quê?
Os projetistas do ASP.NET ao invés de deixarem á cargo do Desenvolvedor a definição COMPLETA da apresentação de alguns dos seus componentes, preferiu encapsular esse detalhe.
Esse comportamento não é apenas visto para o ASP.NET não, outros frameworks de outras tecnologias web também fizeram o mesmo:
Geram HTML desnecessário tanto encapsulados pelo seu próprio framework ou pela própria ferramenta IDE em questão como o Visual Studio.
Com essa característica, se quisermos implementar uma solução baseada em Padrões Web, muitas vezes temos que recorrer àquela solução usada inicialmente pelo ASP. 3.0. Ou seja, temos que implementar nosso próprio meio de exibir nosso conteúdo ao invés de adotar a solução mal feita e nativa do próprio Framework que apesar de belíssimo no sentido Arquitetural, deixa a desejar quando a questão é a customização da apresentação.
Dentro desse contexto vemos o surgimento de "Frameworks para Frameworks" como poderia ser definido o belo
ASP.NET 2.0 CSS Friendly Control Adapters. Que nada mais é do que uma forma de driblar o que o framework do asp.net faz erradamente: encapsular a apresentação de controles HTML.
Vejam a primeira frase da introdução do framework:
ASP.NET is a great technology for building web sites but it would be even better if it provided more flexibility for customizing the rendered HTML
Cool!
Ainda não vi à fundo o novo .NET Framework 3.5, parece-me que tem bastante novidades para alguns controles, mas para o 2.0, temos ainda dificuldade.
Estarei publicando posts sobre como driblar essa característica e facilitar a adequação de um sistema feito em ASP.NET para Padrões Web, esse último que ainda estou a estudar.
São detalhes que passam por todos os papéis desempenhados na construção ou idealização do site, como por exemplo:
- O Engenheiro de Front-End deve especificar um HTML padronizado, rápido, semântico, etc;
- O Desenvolvedor deve programar se preocupando em gerar o código adequadamente;
- O Arquiteto, pode intervir e escolher as melhores práticas, métodos ou componentes para alcançar o objetivo;
- Padrões ou regras como o YSlow afetam todos esses profissionais que tem que se desdobrar para chegar a um nível de aceitação plausível;
E muito mais!
Vemos que a tarefa não é fácil e pode chegar até aos Editores de Conteúdo, pois são eles que colocam o conteúdo no site.
Você deixará com eles a tarefa de cadastrar informação apresentada de qualquer forma?
Talvez! Tudo vai depender do nível de importância que você deseja para esse detalhe no sistema.
É aí que os stakeholders entram em questão.
Todos estão ou serão envolvidos!