 |
Por Dennes Torres  dennes@bufaloinfo.com.brDennes Torres possui as certificações MCAD, MCSD,MCSE, MCDBA e MCT. Atualmente atua como diretor da Búfalo Informática, líder do grupo de usuários DevASPNet, co-lider dos grupos devSQL e getWindows no Rio de Janeiro, podendo sempre ser encontrado na lista de discussão do grupo DevASPNet (devaspnet-subscribe@yahoogrupos.com.br) bem como nas reuniões do grupo. Possui também um blog em http://cidadaocarioca.blogspot.com |
|
|
|
| As novidades do MS AJAX - versão final | |
|
|
|
Durante as versões beta escrevi 2 artigos sobre o AJAX, que podem ser lidos em http://www.bufaloinfo.com.br/artigos/coluna34.asp e http://www.bufaloinfo.com.br/artigos/coluna35.asp , para quem está por fora do AJAX sugiro dar uma lida antes de ler sobre a versão final
Na versão final, porém, ocorreram algumas mudanças. Vamos então começar esta série de artigos sobre a versão final do AJAX falando das mudanças que ocorreram entre os betas e a versão final.
Primeiramente, temos várias biblioteca Ajax, então é bom nos acharmos entre elas, veja :
| Recurso | O que é |
| Ajax Extensions | O núcleo do Ajax em si, junto com alguns poucos webControls (UpdatePanel, etc) |
| Ajax Toolkit | Projeto desenvolvido pela Microsoft em conjunto com a comunidade, de código fonte aberto, criando inúmeros webControls que fazem uso do núcleo do Ajax |
| Ajax Futures | A Microsoft pretende manter sempre esta biblioteca, contendo recursos ainda não prontos e que serão incorporados a futuras edições do Ajax |
| Ajax Library | Uma biblioteca de recursos client que permite o Microsoft Ajax ser utilizado em conjunto com outras tecnologias, tais como PHP, JSP, etc. |
Agora vejamos as novidades do Ajax.
O suporte a webParts foi retirado
No primeiro artigo que escrevi e em um evento do grupo devASPNet fiz exemplos com WebParts sem nenhum problema. Mas na versão final o suporte a webParts foi removido.
Existem comentários de existir o suporte a webParts na biblioteca Ajax Futures, mas não tive sucesso na implementação. O suporte a webParts é algo que ficará para uma próxima edição do Ajax.
O suporte aos validadores foi retirado
Existem alguns bugs conhecidos entre os validadores e o updatePanel. Não em situações simples, mas em determinadas situações complexas envolvendo o uso dos validadores (não encontrei documentação, testei várias situações simples que funcionaram bem).
Para resolver o problema durante algum tempo as versões beta do Ajax pediam que o seguinte trecho fosse inserido no web.config :
<tagMapping>
<add tagType="System.Web.UI.WebControls.CompareValidator" mappedTagType="Sample.Web.UI.Compatibility.CompareValidator, Validators, Version=1.0.0.0"/>
<add tagType="System.Web.UI.WebControls.CustomValidator" mappedTagType="Sample.Web.UI.Compatibility.CustomValidator, Validators, Version=1.0.0.0"/>
<add tagType="System.Web.UI.WebControls.RangeValidator" mappedTagType="Sample.Web.UI.Compatibility.RangeValidator, Validators, Version=1.0.0.0"/>
<add tagType="System.Web.UI.WebControls.RegularExpressionValidator" mappedTagType="Sample.Web.UI.Compatibility.RegularExpressionValidator, Validators, Version=1.0.0.0"/>
<add tagType="System.Web.UI.WebControls.RequiredFieldValidator" mappedTagType="Sample.Web.UI.Compatibility.RequiredFieldValidator, Validators, Version=1.0.0.0"/>
<add tagType="System.Web.UI.WebControls.ValidationSummary" mappedTagType="Sample.Web.UI.Compatibility.ValidationSummary, Validators, Version=1.0.0.0"/>
</tagMapping>
Estre trecho estava na verdade substituindo os validadores tradicionais do .NET por classes equivalentes que haviam sido criadas dentro da biblioteca do Ajax, mas com suporte ao Ajax. Então estavamos na verdade deixando de utilizar os validadores do .NET e passando a utilizar os validadores do Ajax.
Na versão final esses validadores substitutos foram retirados. Muitos se perguntaram : por que ?
Por que isso não resolveria de todo o problema, especialmente para desenvolvedores de componentes. Alguém que tivesse desenvolvido um validador personalizado continuaria com problemas no uso do Ajax. Quando um desenvolvedor resolvesse desenvolver um validador personalizado, de qual herdaria, do que tem suporte ao Ajax ou do que não tem ?
Então acharam melhor cortar a duplicidade de validadores e lançar via Windows Update uma correção no System.Web do framework .NET. Enquanto este update não é liberado, disponibilizaram a dll dos validadores substitutos, com código fonte, para quem tiver problemas com os validadores.
Vocês podem ver mais a este respeito em http://smarx.com/posts/what-happened-to-the-validators-in-asp-net-ajax-1-0-rtm.aspx e http://blogs.msdn.com/mattgi/archive/2007/01/23/asp-net-ajax-validators.aspx
Update Progress
O update Progress agora suporta apenas um updatePanel que precisa estar diretamente ligado a ele através da propriedade AssossiatedUpdatePanelID do updateProgress.
Com isso se tivermos vários updatePanels na página precisamos ter um UpdateProgress para cada UpdatePanel.
Retificando (20/03) : Se a propriedade AssossiatedUpdatePanelID do UpdateProgress estiver em branco, ele será exibido para todo e qualquer update Panel da página, mesmo que este updatePanel já tenha um UpdateProgress ligado a ele.
Fico imaginando a seguinte situação : 5 updatePanels em uma página. Um deles precisa de um UpdateProgress diferente. Os outros vão usar o mesmo UpdateProgress. Para este que precisa de um UpdateProgress diferente, teremos 2 UpdateProgress aparecendo, já que o UpdateProgress não respeita o fato do updatePanel já ter outro UpdateProgress associado a ele.
Mudanças no Update Panel
Propriedade UpdateMode
A propriedade UpdateMode determina se a atualização será feita sempre que ocorrer uma ida ao servidor ou apenas se o conteúdo do updatePanel for atualizado. Esta propriedade foi incluida pensando em cenários em que hajam vários update panels na mesma página. Nestes cenários pode-se colocar o valor da propriedade para "Conditional", de forma que o updatePanel apenas se atualize se algo mudou em seu conteúdo.
Mas não se engane : Isso só afeta a renderização no client, transmissão por rede talvez, mas não o processamento no servidor. Cada ida de um UpdatePanel ao servidor gera um processamento completo da página, mesmo que não tenha sido aquele updatePanel que causou a ida ao servidor.
Vamos demonstrar isso :
1) Crie um novo Atlas webSite
2) Crie dois web user controls, Clientes.ascx e Produtos.Ascx
3) Em Clientes.ascx, crie um datasource apontando para o banco northwind, tabela customers (customerid, companyname, contactname, country). Nas advanced options, habilite atualizações
4) Crie uma gridview ligada a esse datasource e faça o auto-format
5) habilite a paginação e edição da gridview
6) Em Produtos.ascx crie um datasource apontando para o banco northwind, tabela products (productid, productname, unitprice, unitsInStock)
7) Insira uma gridview apontando para este DataSource e faça o auto-format
8) Habilite a paginação da gridview
9) No evento load do user control produtos.ascx programe o seguinte :
Gridview1.databind
(a gridview mantém estado por natureza, ela não irá ao banco se não for alterada. Mas no exemplo que faremos a questão é se esta linha irá ou não ser executada)
10) Abra a default.aspx e confira que já existe um scriptManager na página
11) Insira um UpdatePanel (UpdatePanel1)
12) Dentro do UpdatePanel insira o user control clientes.ascx
13) Insira outro updatePanel (UpdatePanel2) abaixo e fora do primeiro.
14) Insira o usercontrol produtos.ascx no updatePanel2
15) Configure o updateMode dos dois updatepanels como conditional - só se atualizam se necessário.
16) Execute a aplicação. Na primeira abertura da página ambos os bancos serão chamados.
17) Abra o sql server management studio.
18) Em tools, Abra o SQL Profiler
19) Clique em "New Trace", quando solicitado logue-se e utilize as configurações default.
20) Pagine a gridview de clientes várias vezes.
Observe que apesar da gridview de clientes estar em um updatePanel separado e ambos estarem configurados com o updateMode Conditional, tanto a tabela de clientes como de produtos são acessadas. Esse exemplo demonstra que o updatePanel, ao ir ao servidor, processa toda a página e não apenas um pedaço. Ele apenas mascara isso do usuário e economiza um pouco em renderização e provavelmente em transmissão pela rede, mas não em processamento do servidor.
ChildrenAsTriggers
Esta propriedade define que o updatePanel deve considerar todos seus objetos filhos como triggers para causar um postback assincrono. Mas já não é isso mesmo que ele faz ?
Pois é, por isso essa propriedade vem marcada como true por default.
O uso desta propriedade vai ficar mais claro quando observarmos os tipos de triggers
Tipos de triggers
Durante a versão beta tinhamos triggers e pronto. Agora temos 2 tipos de triggers : AsyncPostBackTrigger e PostBackTrigger
AsyncPostBackTrigger : Este é o velhor trigger que conhecemos. Apontamos este trigger para um objeto fora do updatePanel, escolhemos o evento e pronto : Aquele evento vai disparar a atualização assíncrona do updatePanel.
Mas este trigger também pode ser apontado para objetos dentro do updatePanel. Mas com que utilidade ? Em alguma situação complexa o ChildrenAsTriggers poderia estar como false e alguns AsyncPostBackTriggers apontando para objetos dentro do updatePanel determinando o que causaria a atualização assíncrona.
PostBackTrigger : Este trigger funciona como um trigger de excessão. Apontamos para um objeto contido dentro do updatePanel e o trigger faz com que este objeto cause um postback real, ao invés de um postback assíncrono.
Para fazer com que um elemento de um container (como um botão da gridview) passe a causar o postback da página, precisamos utilizar o método registerPostBackControl do scriptManager.
Vamos fazer isso utilizando nosso exemplo anterior, vamos utilizar o user control clientes.ascx
1) Transforma a coluna de botões (commandField) em template
2) Entre em Edit Template e verifique o nome do botão editar. Saia da edição do template.
3) Entre no evento rowDataBound da GridView
4) Programe o seguinte código :
If e.Row.RowType = DataControlRowType.DataRow And e.Row.RowState <> DataControlRowState.Edit Then
Dim lk As New LinkButton
lk = e.Row.FindControl("NomedoSeuLinkButton")
ScriptManager1.RegisterPostBackControl(lk)
End If
5) Teste a aplicação. Você irá observar que o botão editar da gridview de clientes passou a causar postback, enquanto que os demais continuam fazendo a chamada assíncrona ao servidor.
ScriptManager
EnablePartialRendering
Agora o EnablePartialRendering vem definido como true por default, afinal em 99.9% dos casos é isso que desejamos mesmo.
EnableGlobalization
Por algum motivo desconhecido, a globalização no Ajax depende não só das configurações da página e do web.Config, mas também de que a globalização esteja habilitada no ScriptManager através desta propriedade.
Registrando javascripts
Gerar uma mensagem em javascript ou abrir um popup são tarefas bem comuns, mas se forem feitas no meio de uma renderização parcial de um updatePanel podem gerar problemas.
Para resolver o problema o scriptManager passou a ter métodos shared para fazer o registro de javascript. Desta forma ele garante a compatibilidade com a geração de javascript por objetos que estejam dentro de updatePanels.
Instalação do Ajax Control Toolkit
A instalação dos templates do Ajax Control Toolkit não é intuitiva e pode confundir. Depois de descompactar a pasta contendo o toolkit é necessário executar o arquivo em AjaxControlExtender\AjaxControlExtender.vsi
O Toolkit instalará os projetos de template para sites usando o toolkit e para control extenders com o toolkit
Deployment
Na instalação do MS Ajax as DLLs do Ajax (System.Web.Extensions e System.Web.Extensions.Design) são inseridas no GAC (Global Assembly Cache) de sua máquina.
Consequentemente os templates de projeto habilitados para o MS Ajax não copiam as DLLs para o seu diretório BIN
Mas existe um motivo muito especial disso acontecer : As DLLs do Ajax utilizam Reflection e Reflection é um recurso do .NET que apenas pode ser utilizado quando o site roda em Full Trust, o que não é bom para provedores de hospedagem.
Existem duas formas de uma dll ter Full Trust :
1) O site todo ganhar Full Trust
2) A dll estar no GAC
Você não tem acesso ao GAC do provedor, então vai depender de que o provedor de suporte ao uso do Ajax.
Existe, porém, uma alternativa, mas que só funciona em provedores mal configurados :
1) Obtenha uma cópia das DLLs. Elas estão no GAC, você tem que conseguir captura-las
a) Crie um projeto windows
b) Faça referência para as DLLs System.Web.Extensions e System.Web.Extensions.Design
c) Utilizando a janela de propriedades, mude a propriedade Copy Local para true
d) Compile o projeto. As DLLs aparecerão em seu diretório BIN
2) Copie as DLLs para o diretório BIN de sua aplicação web
a) Se você tentar executar neste momento, verá o seguinte erro :
3) No web.config, adicione a seguinte tag :
<trust level="Full" />
4) Teste a aplicação
É dificil saber o que é pior : Se funcionar é porque seu provedor não soube configurar corretamente os trust levels, se não funcionar você terá que depender deles para instalarem o MS Ajax
