Fico sempre feliz em ver novos artigos e assuntos sobre AJAX.NET em nossa língua. Algumas das vezes ocorrem alguns "deslizes" e a informação passada nestes artigos não é correta ou imprecisa. Sempre que escrevemos um artigo corremos o risco de errar, seja por descuido, seja pelo fato de não conhecer os detalhes da implementação...., Claro que isso não desmerece o artigo nem seu autor, em 90% dos casos os artigos são ótimos e atingem seu objetivo.
Como MVP, acabo tendo a preocupação de estar compartilhando corretamente a informação para uma perfeita compreensão do desenvolvedor e por conseqüência a melhor utilização dos recursos e das tecnologias envolvidas e discutidas.
Este fim de semana me deparei com alguns destes artigos (em diversos sites) com pequenos “deslizes” que podem dificultar ou ainda se tirar conclusões erradas de como utilizar o AJAX.NET.
Como já tinha prometido em várias palestras falar um pouco mais em detalhes do AJAX, resolvi então compartilhar neste blog alguns dos detalhes que saíram na versão final do AJAX.NET que eventualmente são passados com alguns “enganos”.
A estrutura do AJAX.NET :
o Ajax.Net possui apenas uma única biblioteca e não várias. Por se tratar de um framework que interage tanto com o lado cliente como o lado servidor da aplicação sua estrutura é divida assim:
Ajax Extensions - Núcleo do lado servidor onde se encontra os Server-Controls. São estes controles que permitem tornar as aplicações "AJAX Enabled" pelo modelo de programaçãp Server-Centric.
A dll do AJAX Extension já possuem as bibliotecas do AJAX Library (Elas estão embeding na DLL System.Web.Extensions).
Ajax Library – Núcleo do lado cliente onde se encontra as bibliotecas em Javascript. Por se tratar de um conjunto de funcionalidades escritas em Javascript sem dependências direta do AJAX Extensions pode ser usada em ambientes e linguagens que suportam javascript tais como PHP. Esta biblioteca é a mesma que se encontra no AJAXExtension . É pelo uso desta biblioteca que tornamos as aplicações "AJAX Enabled “ pelo modelo de programação Client-Centric.
Um “mix” de ambos os recursos normalmente é o desejado quando queremos tirar o máximo de proveito da produtividade obtida no modelo Server-Centric e o máximo de flexibilidade e controle encontrados no modelo Client-Centric.
Alem da versão RTM do Ajax.Net a MS vem disponibilizando para comunidade uma versão chamada “AJAX Future XXX CTP” onde XXX é referente ao mês que foi lançado. Esta versão possui a mesma estrutura da versão RTM, porem é incluída alguns controles e funcionalidades que poderão fazer parte do produto em versão futuras. O objetivo desta versão é que a comunidade possa testar e dar feedbacks em relação aos novos recursos, sendo assim, algumas destas funcionalidades podem não estar completas nem são suportadas oficialmente.
O AJAXTOOLKIT
O AJAXToolkit embora esteja diretamente ligado ao produto AJAX.NET não faz parte do produto e pode ser “baixado” posteriormente. O AJAXTOOLKIT é um conjunto de controles que faz uso do núcleo do AJAX.NET.
Seu objetivo é ser uma caixa de ferramenta de controles que facilitam o desenvolvimento de interfaces ricas com o uso de AJAX.
Atualmente existem mais de 30 controles criados para as mais diversas finalidades, e entres eles, um de nossa autoria, e dentro em breve, teremos mais outros 2 controles que estamos trabalhando.
De um modo geral os controles são do tipo Extender, ou seja, eles expandem as funcionalidades de um controle já existente fornecendo novas funcionalidades e comportamentos.
Em seu útimo release foi incluído o suporte a globalização de mensagens, aplicação de themes e consolidado o uso de CSS resource (uma fantástica feature).
Atualmente todo o team esta focado e garantir uma melhor estabilidade de todos os controles já publciados, para depois podemos avançamos com novos controles, mas posso adiantar que existem pelo menos 2 grandes controles sendo desenvolvidos :
a) MenuContext
b) AJAX WYSIWYG Editor
alem dos 2 controles que estamos criando :
c) TextCount Multiline
d) Calulator Control.
Um dos grandes atrativos do AJAXTOOLKIT que ele esta hospedado no site Codeplex (http://www.codeplex.com/AtlasControlToolkit), tendo seu código aberto e comentado. Isso permite que a comunidade possa interagir com o Team de desenvolvimento apontando bugs e melhorias, alem claro de ser uma fonte muito rica de exemplos de código usando o modelo Client-Centric. O Ajax Toolkit também possui um template para ser instalado no VS que facilita muito a criação de novos controles já criando uma estrutura padrão.
WebParts em AJAX.NET
O suporte para WebParts no AJAX.NET não esta disponível em sua versão RTM 1.0 . Durante o desenvolvimento até a entrada da versão beta fazia parta da versão CTP. Nas versões betas já houve a separação, pois ainda teremos muitas mudanças nestes cenários (provavelmente em função do “Orcas” que já promete grandes novidades). Sendo assim, esta funcionalidade ficou na versão “Future” e a exemplo de outros recursos como DragAndDrop . O núcleo dos controles de Webparts será substituído quando ela fizer parte da versão final (como esta sendo feito com os controles Validators – Ver a seguir).
Uma dica para quem for testar a versão “Future January CTP” é que se torna necessário fazer o mapeamento das tags para que funcione de forma correta uma vez que os controles de webparts que vem por default no asp.net não estão preparados para interagir com o AJAX. Isso é necessário porque os controles webparts estão reescritos em outro namespaces (Veja figura abaixo).
O mapeamento pode ser visto no arquivo web.config que esta no mesmo diretório da versão “Future”.
A thread abaixo mostra um resumo ,porem muito claro do que podemos fazer com WebPats usando a versão "Future January CTP"
http://forums.asp.net/thread/1545256.aspx
Validators em AJAX.NET
O suporte para validator no AJAX.NET não foi retirado propriamente dito, na maioria dos cenários usuais o núcleo do AJAX.NET da o suporte adequado.
Um dos problemas de compatiblidade é quando os validator estão dentro de UpdatePanel em determinadas situações ele não é capaz de resolver o render e localização do controle (normalmente durante o processo de partial render). Isso ocorre porque ele não acha o elemento DOM referente ao validator, pois o “parent” do controle esta sobre o updatePanel e o script do asp.net faz a busca pelo array “Page_Validators“ que tem seu “parent” para nothing ou outro elemento acima.
Uma forma de resolver isso foi criação de uma biblioteca de compatibilidade (aconteceu na versão beta1) e incluir o suporte ao validator dentro do AJAX.NET mapeando as tags originais para os novos controles. Infelizmente esta abordagem trouxe problemas uma vez que controles criados pelos desenvolvedores que herdavam da classe System.Web.UI.WebControls.BaseValidator precisariam ser alterados para herdar da classe de compatibilidade o que gera diversos problemas com legados e confusão de qual classe será usada como herança.
Sendo assim já na versão BETA2 do AJAX.NET esta classe de compatibilidade foi retirada e passamos novamente utilizar as classes originais (Sofri com isso pois precisei rever um de meus controles do já estava em fase de publicação no AJAX Toolkit) .
Na versão final este conceito foi mantido, e será feito uma atualização no núcleo do Framework (via Windows Update) para atualizar as classes originais. Enquanto esta atualização não chega uma saída é utilizar estas classes de compatibilidade quando necessário. Para isso você devera baixar o código fonte das classes, referenciar em seu projeto a DLL que contem estas classes e alterar o web.config para mapear os validator para esta classe. Todos estes detalhes podem ser visto neste blog:
http://blogs.msdn.com/mattgi/archive/2007/01/23/asp-net-ajax-validators.aspx
UpdateProgress com mais de um UpdatePanel
Quando passamos a usar AJAX.NET , por não haver refresh de tela, quando são executadas as chamada assíncronas torna-se necessário darmos um feeedback para o usuário avisando que sua requisição esta sendo processada. Para atender este necessidade foi criado o UpdateProgress presentes desde as versões antigas dos CTPS.
Umas das muitas solicitações feita pela comunidade durante o desenvolvimento do produto era poder associar o Updateprogress a um updatePanel específico. Estas solicitação foi atendida na beta 2 e na versão final, e passamos a ter a opção de pode ou não associar um updateprogress a um updatepanel especifico através da propriedade AssociatedUpdatePanelID. Demostramos isso em detalhes em nossa palestra durate o TechED2006.
DICA: se a propriedade AssociatedUpdatePanelID ficar vazia , o updateprogress será ativado para qualquer updatepanel presente no formulário, inclusive os que estiverem com a proriedade preenchida, ou seja, Mesmo que tivermos vários updatepanels em uma pagina não precisamos criar um updateprogress para cada um, esta sera uma decisão de usabilidade e não uma restrição do controle como da a enteder em alguns artigos.
O uso do UpdatePanel
Este é o principal componente do lado Server. O updatepanel é um componente que faz a herança do conhecido componente Panel, ou seja, ele é um Container (Componente que permite que seja colocado outros componentes em seu interior).
Seu objetivo é bastante simples: Tudo que for colocado “dentro” do UpdatePanel passará a interagir com o servidor de forma assíncrona fazendo chamadas pelo objeto XMLHTTP Request sendo controlado pelo controle ScriptMananger. Assim quando é feito uma requisição de página esta é feita pelo função Javascript e não mais pela página usando o método Onsubmit.
Um engano comum é achamos que com isso o processo no lado servidor é modificado, Não é!. Continuamos a ter o postback e o disparo e seqüência de todos os eventos normais de uma requisição de página no servidor. O que muda não é o processamento no lado do servidor e sim o controle e gerencia do que será trafegada entre o servidor e a função/classe chamadora no lado cliente (leia-se o código Javascript que foi o responsável pela chamada).
Como existem diversos cenários para as aplicação no mundo real passou a existir a necessidade de prover algumas funcionalidades extras ao controle updatepanel com o objetivo otimizar as chamadas evitando roundtrips desnecessárias ao servidor(Quando isso fosse possível). Esta necessidade levou as mudanças presentes na versão final, que passou a ter uma melhoria significativa sobre o controle de envio e também quando e como eles são disparados. As propriedades que dão esta flexibilidade são:
ChildrenAsTriggers : Usado para alterar o comportamento padrão do updatepanel (Que assume que todos os controles em seu interior farão chamadas assíncronas). Quando esta propriedade é alterada para “false” , o updatepanel passa e verificar a forma de envio através das propriedades AsyncPostBackTrigger e PostBackTrigger.
AsyncPostBackTrigger : Usando para informar quais controles farão chamadas assíncronas. Podem ser informados controles dentro do UpdatePanel ou fora dele. Em ambos os casos o evento postkback gerado pelo controle informado será capturado e tratado pelo scriptMananger evitando-se assim uma chamada ao servidor pela forma tradicional.
PostBackTrigger : Uma vez que podemos alterar o comportamento default do updatepanel para não executar postbaks assíncronos para todos os controles dentro do updatepanel podemos com esta propriedade informar quais os controles dentro do updatepanel que farão as chamadas ao servidor executando um postback tradicional.
As combinações possíveis com estas três propriedades proporcionam ao desenvolvedor, um leque de opção para criar os mais diversos e complexos cenários, tornado o updatepanel bastante flexível no seu uso e na sua aplicabilidade.
O uso adequado destes recursos possibilita ganhos significativos de desempenho e tráfego, sendo um dos itens que sempre devem ser analisados durante o projeto ou migração para o uso do AJAX.
ScriptMananger
Finalmente chegamos ao ScriptMananger. Este controle, que só aparece em tempo de Design, é o responsável por todas as chamadas e retornos que são feita de forma assíncrona.
É graças a ele que podemos fazer o render parcial da página, localizar quais os controles que serão alterados e como serão alterados. Não houve mudanças significativas durante a passagem da versão Beta para a versão RTM, porem alguns cuidados são necessários em especial quando manipulamos tipos de dados sensíveis a localização.
O AJAX funciona dividindo parte do processamento entre o servidor e o cliente, preferencialmente entregando apenas os dados e deixando para o lado cliente transforma os dados na melhor forma de apresentação, isso todos já sabem.
Todo este processo de divisão se faz serializando os dados de forma que possam ser trafegados entre o servidor e o cliente pelo protocolo Http, isso nem todos sabem .
É justamente devido ao processo de serialização e “deserialização“ que precisamos ficar atentos quando tivemos manipulando dados do tipo Data (por exemplo) que é sensível a localização. Nestes cenários precisamos de alguma forma avisar, caso seja necessário, ao lado cliente escrito em javascript , que desejamos que o dado enviado, sofra uma transformação de conversão para a cultura corrente, que pode ou não ser necessário. Justamente neste cenário é que precisamos ativar uma das propriedades do ScriptMananger :
EnableScriptGlobalization : Seu default é false, ou seja não é feito nenhum tratamento de conversão dos dados serializados. Lembra-se que dissemos que o envio não era mais feito pela página e sim pelo XMLHTTP, por isso precisamos informar como desejamos fazer.
Alguem já teve problemas com acentuação ? Provavelmente sim. Mas sabem porque ? Justamente pro causa deste efeito, uam forma de solucionar e termos uma cultura para UI e outra para os dados que são trafegados, issso claro quando não precisamos manipular os dados pelo javascrit, que é o caso que estamos tratando aqui.
Mais detalhes sobre este assunto pode ser visto em :
Sobre a proriedade EnableScriptGlobalization :
http://ajax.asp.net/docs/mref/P_System_Web_UI_ScriptManager_EnableScriptGlobalization.aspx
Sobre como serialziar pelo lado Servidor:
http://ajax.asp.net/docs/mref/N_System_Web_Script_Serialization.aspx
Sobre como serialziar pelo lado Cliente:
http://ajax.asp.net/docs/ClientReference/Sys.Serialization/JavascriptSerializerClass/default.aspx
Um efeito e necessidade prática pode ser vista quando usamos o controle Calendar (presente no AJAXTOOLKIT) :
http://www.u2u.info/Blogs/Kevin/Lists/Posts/Post.aspx?List=6f246d9a%2De4e7%2D4846%2Db776%2Df9a62112ffb7&ID=6
E por fim outra explicação de um cara que sou Fã : o Dino Esposito
http://blogs.ugidotnet.org/dinoes/archive/2007/02/06/69915.aspx
Como pode ser observado os motivos de utilziação do EnableScriptGlobalization são muto bem conhecidos, e sua compreenção é fundamental para que o desenvolvedor sabia quando e porque fazer uso deste recurso.
Considerações sobre Deployment
Desde a versão BETA2 houve mudanças significativas no core de Ajax que passou a fazer uso de reflexão. Devido a esta nescessidade a DLL precisa ter permissão de FULL TRUST. Existem 2 formas que conheço e uma terceira que não tenho certeza de como implementar para termos esta permissão :
a) Dar permissão FULL TRUST a aplicação do servidor web
b) registrar a DLL no CAG do servidor que tem permissão FULL TRUST.
Por motivos de segurança a maioria dos servidores de hospedagem compartilhada rodam com permissão MEDIUM TRUST (Que não permitem por default as operações de reflexão) nas aplicações.
A terceira opção (que não posso afirmar) é apenas dar permissão FULL TRUST para as operações de reflexão (vi isso em um grande host que roda em MEDIUM TRUST porem foi possível trabalhar com a versão BETA2 apenas colocando as DLL’s do AJAX na pasta bin, daí acredidar que isso seja possível... mas novamente posso estar enganado)
Abaixo alguns links interessantes para se aprofundar sobre Code Access Security in ASP.NET 2.0
http://msdn2.microsoft.com/en-us/library/ms998326.aspx
http://msdn2.microsoft.com/en-us/library/ms998341.aspx
Esta mudança não preciso dizer causou uma série de transtornos até a entrega da versão final, uma vez que a grande maioria dos hosts de hospedagem tem resistência de registrar DLL no gac em versão beta ainda (eu particularmente senti isso na pele ao ter que esperar a versão Final para publicar 100% de meu site dentro do meu Host).
Com o lançamento da Versão final praticamente os problemas deixaram de existir e a grande maioria dos hosts sérios passaram a suportar o AJAX.NET registrando as DLLS no GAC e mantendo suas políticas de Code Access Security em MEDIUM TRUST.
Uma observação interessante é que esta forma de deployment sinaliza que provavelmente nas versões futuras do framework não será necessário baixar em separado as dlls do AJAX.NET uma vez que será instalado junto com o framework e colocado as dlls no GAC (como deverá ser Tb a atualização dos validators controls já citados).
O que temos pela frente
O AJAX.NET com certeza é uma fantástica ferramenta para tornar nossas aplicações mais ricas , com maior usabilidade e interatividade e são percebidas de imediato pelo usuário final.
Podemos esperar muito mais coisa pela frente. Já estamos trabalhando com uma versão do AJAX TOOLKIT para o novo visual Studio codename: ORCAS, que vira com uma infinidade de recursos.
Alem do “Orcas” teremos também o WPF/E (ainda vou falar muito sobre ele) que vai elevar as experiência no uso de imagens e sons na web a níveis imagináveis.
Assisti uma demonstração que não é pública (infelizmente) que em dado momento não sabia mais se estava vendo uma aplicação sobre a web ou se a mesma estava rodando com o aero do Vista , algo realmente impressionante.
A esta altura você já deve estar se perguntando se o que estará fazendo com AJAX será perdido com a chegada do WPF/E. O que posso dizer é que não será perdido, pelo contrario você estará mais familiarizado com uma nova forma usabilidade proporcionada hoje pelo AJAX e será muito mais fácil entender e aplicar o WPF/E, que não substitui o Ajax, pelo contrário ira fazer bastante uso dos conceitos e de seus recursos.
Conclusão
Espero que com este post possa ter ajudado o leitor a entender melhor alguns dos conceitos novos que foram criados e implementados na versão final do AJAX.NET e o mais importante, não apenas saber dos do conceitos mas o porque de sua necessidade e/ou aplicabilidade.
Costumo finalizar minhas apresentações de AJAXcom uma frase :
“Um problema pode ser visto de vários ângulos. Descobrir novas visões do mesmo problema é a arte de saber encontrar a melhor solução.”
Tenha sempre isso em mente quando for aplicar Ajax em sistemas já existentes, lembre-se que toda as interfaces e a usabilidade foi pensada sem o uso de AJAX. Apenas aplicar updatepanels nas interfaces sem uma analise melhor de usabilidade pode resultar em uma interface mais “pobre” que a original. Todas as interfaces devem ser repensadas de forma a se tirar o máximo de proveito dos novos recursos com o mínimo de tráfego entre o cliente e o servidor.
A todos que chegaram ate aqui, uma ótima semana!