Mantendo a rolagem da página entre postbaks usando MaintainScrollPositionOnPostback

Olá.

Hoje venho apenas trazer uma dica rápida.

Supondo que tenhamos um formulário muito grande, que extrapola o tamanho vertical da tela, ele será exibido no navegador com a barra de rolagem do lado direito da tela.
Ao preencher as informações do formulário a aplicação muitas vezes necessita realizar algum ou vários postbacks.
Logo, é necessário mantermos o foco no local onde o usuário está trabalhando, sem que ele seja obrigado a rolar a página todas as vezes que a página for recarregada.

No ASP.Net 1.0 e 1.1 utilizávamos a opção “SmartNavigation” da diretiva Page em cada página que desejássemos adicionar este comportamento.
Caso desejável poderíamos incluir uma opção no web.config para habilitar tal opção para toda a aplicação:

<page smartNavigation="true" />

O SmartNavigation trabalhava com IFrames para conseguir tal comportamento.

No ASP.Net 2.0 o SmartNavigation foi substituído pela opção “MaintainScrollPositionOnPostback”.

MaintainScrollPositionOnPostback aceita true ou false e mantém a posição da rolagem da página entre os pastbacks da mesma sem usar o recurso de IFrame.

Abraços e até o próximo post.

Definindo Media Type usando Themes, Skins e CSS

Olá.

Quem já trabalha com Themes e Skins provavelmente sabe como o ASP.Net 2.0 se comporta.

Basicamente, o que acontece é que, quando uma página utiliza um certo Theme, o ASP.Net automaticamente registra todos os Cascading Style Sheets (CSS) do Theme em questão.
Não há necessidade de usarmos a tag “link” do HTML para todas as folhas de estilo que temos em nossa aplicação.

Isso é particularmente importante quanto temos mais de uma folha de estilo definindo classes com o mesmo nome mas que devem ser carregadas condicionalmente, de acordo com o Theme utilizado. Basta que coloquemos cada folha de estilo correspondente ao Theme dentro de sua respectiva pasta.

Quando o ASP.Net constrói a página, além de aplicar o Theme desejado, ele registra todos os “.css” que estão na pasta do respectivo Theme.

Seria perfeito não fosse o fato de que, muitas vezes necessitamos ter estilos distintos para cada tipo de mídia como, por exemplo, um estilo para exibição na tela e outro para impressão.

Normalmente registraríamos o “.css” desta maneira:

<link href="App_Themes/Default/Print.css" type="text/css" rel="stylesheet" media="print" />
<link href="App_Themes/Default/Screen.css" type="text/css" rel="stylesheet" media="screen" />

Acontece que, ao registrar a folha de estilo automaticamente, o ASP.Net não permite que definamos o Media Type.

Ele simplesmente registra os “.css” como abaixo:

<link href="App_Themes/Default/Print.css" type="text/css" rel="stylesheet" />
<link href="App_Themes/Default/Screen.css" type="text/css" rel="stylesheet" />

Uma das soluções que encontramos foi criar uma classe herdada de HTMLHead que adicionasse alguma lógica para que o registro das folhas de estilo fosse feito corretamente.
Quem quiser se aventurar por esta solução visite o link The Problems with Themes, Skins, and Cascading Style Sheets (CSS) in ASP.NET 2.0 – Defining a Media Type(s).

Os problemas que vejo nesta solução, apesar de funcionar de maneira esperada, é que tiramos a decisão do registro dos estilos das mãos dos designers e levamos para o programador.

A solução que mais se aproxima do mundo ideal é dada pela própria W3C na definição dos Media Types em seu site.

Pela definição do W3C, uma folha de estilo pode possuir rules do tipo @media.

Desta forma, trabalharíamos da seguinte maneira:

@media print {
BODY { font-size: 10pt }
}
@media screen {
BODY { font-size: 12pt }
}

Na verdade, nem precisamos separar os estilos para tela e para impressão em dois arquivos. Eles podem ser definidos em um único “.css”, onde os estilos referentes a “screen” e “print” estão em suas respectivas rules.
Talvez valha separar os estilos em arquivos por mídia apenas por uma questão de organização, mas não por obrigação.

Por enquanto é só.

Abraços e até o próximo post.