Revista MSDN Magazine Edição 06 - Paginação no lado cliente para DataGrids

Restaurar o índice da página atual a partir dos dados de postback em LoadViewState tem algumas vantagens. Primeiro, não é possível definir o índice da página atual até que o controle seja preenchido com itens, e é em LoadViewState que o controle é preenchido após um postback. Além disso, como LoadViewState é chamado antes de a página disparar um evento Load, o método Page_Load pode ler ClientCurrentPageIndex para descrobrir qual página o usuário estava visualizando quando ocorreu o postback. Isso pode ser importante porque o índice da página atual poderia ser usado para afetar outras alterações na página.

RestoreCurrentPageIndex também é chamado pelo método DataBind de ClientPageDataGrid, mas apenas se não tiver sido chamado a partir de LoadViewState. Por quê? Porque se o view state estiver desabilitado (ou seja, se a propriedade EnableViewState do controle for false), LoadViewState não será chamado pelo runtime do ASP.NET. Se view state estiver desabilitado, a página chamará DataBind para preencher novamente o controle, o que significa que o método DataBind é o local mais apropriado para fazer uma segunda tentativa de restaurar o índice de página atual a partir dos dados do postback.

Você deve ter percebido que o método DataBind do ClientPageDataGrid vincula à fonte de dados não apenas uma vez, mas duas (veja a Listagem 7). A primeira chamada para o método DataBind da classe base (superclasse) fornece uma contagem de registro ao ClientPageDataGrid. A segunda chamada - feita com AllowPaging definido como true e PageSize definido para o record count - produz um DataGrid que contém todos os registros da fonte de dados com um paginador no canto inferior. Esse DataGrid está localizado logo abaixo da superfície de ClientPageDataGrid e funciona como a fonte de toda a renderização.

Outro aspecto incomum do método DataBind do ClientPageDataGrid é que ele converte DataReaders em DataSets. São duas as razões para isso. Primeiro, só é possível vincular a um DataReader uma vez, já que ele é uma fonte de dados forward-only. Segundo, normalmente os DataGrids não suportam DataReaders como fontes de dados se AllowPaging for true, a não ser que AllowCustomPaging também seja true. Converter internamente DataReaders em DataSets resolve os dois problemas de forma organizada e assegura que o ClientPageDataGrid funcione perfeitamente com DataReaders (como faz com DataSets).

Listagem 7 Método DataBind

public override void DataBind ()

{

  if (AllowClientPaging && DataSource != null) {

object OriginalDataSource = null;

// Se a fonte de dados for um DataReader,

// convertê-la em um DataSet

if (DataSource is IDataReader) {

OriginalDataSource = DataSource;

DataSource = DataSetFromDataReader

((IDataReader) DataSource);

}

// Vincular uma vez com a paginação desativada

// (e os eventos ItemCreated e ItemDataBound

// suprimidos) para obter uma contagem de item

_SuppressEvents = true;

AllowPaging = false;

base.DataBind ();

_SuppressEvents = false;

// Vincular novamente com a paginação ativada

// para criar um DataGrid contendo todos os

// itens com um paginador na parte inferior

 PageSize = Items.Count;

AllowPaging = true;

base.DataBind ();

// Restaurar a fonte de dados original

if (OriginalDataSource != null)

DataSource = OriginalDataSource;

// Restaurar o índice de página atual a partir

// de dados de postback se ele ainda não tiver

// sido restaurado

if (Page.IsPostBack && AllowClientPaging &&

!_RestoreCurrentPageIndexCalled)

RestoreCurrentPageIndex ();

  }

  else {

base.DataBind ();

  }

}

Advertências

Existe alguma desvantagem em paginar no lado cliente? Pode apostar que sim. Quanto maior o recordset, mais lento será o carregamento da página, porque a resposta HTTP retornará todos os registros, e não apenas os contidos na página atual. No caso de recordsets relativamente pequenos — digamos, com 1.000 registros ou menos — você provavelmente não se incomodará. No entanto, nos recordsets muito grandes, o tempo de carregamento poderá ser inaceitavelmente alto.

Um fator adicional a ser considerado quando se trata de utilização de largura de banda é a propensão do DataGrid a serializar seus conteúdos em um view state. Os DataGrids maiores aumentam o tempo de download de duas maneiras. Em primeiro lugar, eles geram tabelas HTML grandes. Segundo, eles aumentam o tamanho do view-state. Como o ASP.NET persiste o view state usando um campo hidden, os conteúdos do DataGrid aparecerão essencialmente uma vez em cada solicitação HTTP e duas vezes em cada resposta HTTP. Essa é mais uma razão para manter a contagem do registro pequena e recorrer à paginação no servidor para os recordsets maiores. Se você precisar usar um ClientPageDataGrid para paginar um número grande de registros, considere configurar a propriedade EnableViewState do controle como false e vincule à fonte de dados em cada solicitação de página (em vez de só vincular quando Page.IsPostBack for false). Isso poderia diminuir até dois terços do tamanho da resposta.

Uma última coisa a ser lembrada em relação ao ClientPageDataGrid é que, devido à maneira como ele processa página individuais, você provavelmente desejará tornar o ClientPageSize um número par se usar a propriedade AlternatingItemStyle para processar itens de número ímpar de maneira diferente dos itens de número par. Caso contrário, Page 1 terá um item não-alternante no canto superior, Page 2 terá um item alternante, e assim por diante. O usuário vai se perguntar por que o formato da tabela é alterado a cada vez que ele muda para a próxima página ou para a página anterior.

Conclusão

A classe DataGrid é um ótimo exemplo de um dos recursos mais irresistíveis do ASP.NET: sua capacidade de ocultar lógica comportamental e renderização complexas em classes reutilizáveis. ClientPageDataGrid aperfeiçoa ainda mais a noção de controles server-side e demonstra não apenas como modificar tipos de controle predefinidos de acordo com suas necessidades de trabalho, mas também como estendê-los para adicionar funcionalidade no lado cliente. Controles de servidor que recorrem a scripts no lado cliente para funcionarem de forma mais eficaz são uma idéia que está virando realidade. Espero que os autores de controle concordem comigo.