Skip Navigation Links
Novas Tecnologias
Ferramentas Adicionais
Ferramentas Adicionais
ASP.NET Ajax e AjaxToolkit : Coisas que você não vai achar no manual
Data:3/3/2009

Translate this page now :





Categories: ASP.NET , Ajax

Gostou do texto ? Vote e dê sua opinião! Pontuação atual :
Adicione aos Favoritos!
BlogBlogs Rec6 Linkk Ueba Technorati Delicious DiggIt! StumbleUpon

Veja Também


aspnet A impressão geral que o AjaxToolkit causa quando utilizado em um sistema real é uma só - instável. Mas afinal, por que isso ?

É muito fácil fazer um exemplozinho simples que funcione com ajax e ajax toolkit, mas comece a utiliza-lo em um sistema real e terá todo tipo de problemas possíveis. Depois de muito pesquisar algumas falhas constantes com AjaxToolkit, acabei por descobrir uma grande causa de falhas que aparenta estar totalmente não-documentada.

Uma mensagem nos fórums de ASP.NET gerou respostas de uma única pessoa : "É, acho que você encontrou um bug" - nada animador.

As seguintes mensagens de erro se tornam comuns trabalhando com o AjaxToolkit :

AjaxToolkit is undefined

Sys is undefined

Sys.ArgumentUndefinedException "Value cannot be undefined. parameter name: type" (podendo variar para ID ou baseType)

Existem alguns erros mais do que fundamentais que podem causar as mensagens acima. Então antes de chegarmos ao assunto central deste artigo, vamos analisar algumas soluções básicas, incluindo alguns detalhes de arquitetura.

Arquitetura

Ajax1 Você está utilizando diversos webControls que oferecem funcionalidade de client. É claro que você sabe que estas funcionalidades de client dependem de arquivos javascript. Mas cadê os arquivos javascript ?

Muito antigamente, na época do framework 1.0, mantinha-se uma pasta aspnet_client nos sites, contendo o javascript. Mas isso tornava todo o ambiente de difícil manutenção.

Para resolver este problema surgiu o conceito das scriptReferences : Os arquivos javascript ficam localizados dentro da dll, embeded, como costuma-se chamar.

Os webcontrols, ao precisarem destes arquivos, adicionam uma scriptreference na página. A adição desta scriptreference é feita através do scriptmanager do ajax. O arquivo javascript poderia, sim, ser chamado diretamente, sem a ajuda do scriptmanager, mas isso deixou de ser uma boa prática.

A script reference gera uma tag <script src=""> que faz uma chamada ao servidor indicando o script que deve ser recuperado - e assim ocorre.

Assim sendo cada uma de nossas páginas possui diversas scriptReferences que são geradas pelos nossos webcontrols

Problema Básico

A causa de todos os problemas é muito simples : Se uma das scritpReferences falhar, os scripts não conseguem rodar corretamente - porque frequentemente as referências dependem umas das outras - consequentemente temos os mais diversos erros, dependendo da scriptReference que tenha falhado.

Soluções Básicas

1) Verifique as configurações do projeto. Se as tags do web.config não estiverem corretas, se as versões dos assemblies do ajax/ajax toolkit não estiverem corretas, os scripts serão gerados de forma errada e erros ocorrerão

2) Verifique a data da máquina. O ASP.NET Ajax possui uma validação de datas, ele não aceita entregar scripts se a máquina que está solicitando tiver um data anterior a data de criação do próprio ASP.NET Ajax - 2005

3) Existiu em tempos remotos uma incompatibilidade do ASP.NET Ajax com os validadores. Para resolver esta incompatibilidade foi necessaria a re-criação dos validadores de forma a se tornarem compatíveis com o ASP.NET Ajax

Os novos validadores foram enviados para sua máquina na forma de um pacote do windows update e todos viveram felizes para sempre.

Porém entre a descoberta do problema e o envio da solução via Windows Update foi disponibilizada uma solução alternativa : um assembly com os novos validadores compilados e instruções para usar o tagmapping para desviar os antigos validadores para os novos validadores.

Então, se você der azar  e estiver trabalhando em algum ambiente não muito bem configurado, pode ainda esbarrar com esse problema, apesar de estar se tornando cada vez mais incomum.

4) O toolkitScriptManager foi utilizado no ajax toolkit como solução para otimização da performance/escalabilidade, fazendo uma combinação de scripts dos objetos do ajax toolkit e minimizando assim o número de arquivo a serem baixados. Porém ocorreu uma incompatibilidade documentada entre o toolkitscriptmanager e algumas edições do IE. Já foi corrigido, mas em ambientes não atualizados você pode esbarrar com isso

5) Como último recurso, verifique o codigo fonte da página pelo IE. Localize cada tag script no fonte e, utilizando o browser, chame uma por uma as urls indicadas nas tags script src. O esperado é um arquivo javascript para cada URL. Se alguma das URLs devolver um erro, eis ai a verdadeira causa do problema

Com a SP 1 do Framework 3.5 o toolkitScriptManager acaba sendo deixado de lado, pois o scriptmanager traz como novidade os combinedScripts

Após tudo isso

Se tudo fosse fácil assim, o Ajax Toolkit não teria a fama de instável que tem. Infelizmente as coisas não são tão fáceis e existe a possibilidade de, após todos os passos acima serem seguidos, os erros persistirem.

Neste caso, o que fazer ?

Gambiarra

gambiarra Duas gambiarras parecem estar sendo utilizadas como soluções comuns para muitos problemas fora dos que indiquei acima. São as seguintes :

A) Inserir um objeto do mesmo tipo que o problemático mas sem função alguma - dummy - no topo da página ou da masterpage.

Se o webcontrol em questão está tendo problemas para registrar seus recursos - scriptreferences e webresources - corretamente, o controle dummy pode resolver este problema e ambos, o controle dummy e o correto, estarão compartilhando tais recursos.

O CalendarExtender do ajax toolkit já teve problemas de layout com isso.

B) Descobrir os arquivos javacript que são necessários aos webcontrols utilizados e inserir de forma estática as script references junto ao scriptmanager

Esta solução pode parecer mais bonitinha, mas continua sendo uma gambiarra. As scriptReferences deveriam ser reconhecidas automaticamente e fazer referências estáticas tanto prejudica a manutenção (ter o trabalho de fazer a referência e corrigi-las quando necessário) quanto escalabilidade (se feitas na master page, podem existir referências desnecessárias em algumas páginas).

A Causa

Pode ser que esta causa acabe se unindo a lista de problemas indicados anteriormente, como apenas mais um da lista. No meu caso, porém, se mostrou a causa de inúmeros problemas intermitentes de javascript que pertubaram bastante até que a causa fosse identificada :

UserControls em cache não registram suas script references - caracteristica do @outputcache não gerar processamento algum - mas o html, incluindo algum javascript, são gerados a partir do cache. Este javascript gerado tem dependência de script references que não estarão lá e consequentemente causarão o erro

Pois é. Depois de descoberta a causa, tudo parece de uma lógica incrivemente simples. Ninguém se lembrou de criar nenhum mecanismo que integre o funcionamento do @outputcache com as scriptReferences.

Passo-a-Passo para reproduzir este bug :

1) Crie um projeto para utilizar o ajax toolkit

2) Na default.aspx, insira o scriptmanager

3) Crie um novo user control, teste.ascx

4) No user control, insira uma textbox, um requiredFieldValidator e um botão

5) Na textbox, aplique o textboxWaterMarkExtender

6) No requiredFieldValidator, aplique o ValidatorCallOutExtender

7) Insira o controle teste.ascx na default.aspx

8) Execute a página default.aspx e faça vários refreshs. Nenhum erro

9) No user control, insira o seguinte :

<%@ outputcache duration="40" varybyparam="none" shared="true" %>

10) Execute a página default.aspx e faça refresh. Você verá erros de javascript

Em época em que se fala de scale-Out, projeto Velocity e ASP.NET Cache Extensibility, "esquecer" de permitir que o ASP.NET Ajax (e não estou falando do toolkit, isso é um bug a nível de ajax como um todo) possa funcionar com ambientes de alta escalabilidade é um bug sério.

Para pensar

Tenho dito ultimamente que a tecnologia tem evoluido rápido demais. Parece que os desenvolvedores Microsoft são pressionados demasiadamente a estarem sempre criando tecnologias novas e mais tecnologias novas, sem que estejam tendo tempo de estudar o uso prático da tecnologias já criadas por eles mesmos.

"Ah, mas o uso prático é definido pelos programadores que usam esta tecnologia e fornecem feedback", dizem alguns.

Primeiramente, se assim fosse, por que em quase 4 anos de ASP.NET Ajax - o Ajax surgiu em 2005 - não existe nenhum registro desta incompatibilidade entre scriptReference e @outputcache, algo tão essencial em ambientes escaláveis ?

Os desenvolvedores do mercado não conseguiram realizar em tempo hábil o uso prático do produto conforme o fabricante comodamente esperava. Agora que conseguimos alguns avanços - como identificar o bug acima - os desenvolvedores da Microsoft estão envolvidos com tantas tecnologias a frente (estamos próximos do framework 4.0) que fico com sérias dúvidas sobre o nível de atenção que será dado a isso.

Mesmo que a atenção seja boa, esta chega em um momento em que o tookit já foi taxado pelo mercado como instável, o que é muito perigoso. Estando o fabricante amparado pela grande produtividade de suas ferramentas, ter partes de seu ambiente taxadas de instáveis - consequentemente consumindo justamente a produtividade do desenvolvedor - não é bom, pois o que se ganha de produtividade de um lado pode não compensar o que se perde de outro e começa-se a chegar perto de um balanceamento perigoso da principal vantagem que o fabricante apresenta - a produtividade.

A conclusão é que os desenvolvedores da Microsoft deveriam estar acompanhando muito mais de perto a realidade do mercado - envolvidos eles mesmos com projetos reais de forma a identificarem claramente os pontos fortes e fracos de sua tecnologia - bem antes de seguirem adiante para a próxima tecnologia inovadora

 

As soluções

Não existe solução mágica. A solução ideal depende de mudanças básicas no scriptManager. Nenhuma das duas soluções possíveis é perfeita. Eis as duas :

ScriptReferences estáticas

Descobre-se todas as scriptRereferences que deseja-se utilizar e adiciona-se estas script references de forma estática no scriptManager da master page.

Como descobrir as scriptReferences em uma página :

O scriptManager possui um evento chamado ResolveScriptReference, é um evento chave que nos permite interceptar todos os registros de script e consequentemente identifica-los.

O ASP.NET Futures, uma coleção de futuras tecnologias que virão a ser incorporadas no ASP.NET, possui um componente chamado scriptProfiler que ao ser inserido em uma página exibe todas as scriptReferences utilizadas na página.

O problema é que o scriptProfiler contido no ASP.NET Futures está muito intimamente amarrado com o ajax - o ajax do futures - gerando vários erros quando é utilizado em projetos ajax atuais. Desta forma, achei melhor criar um pequeno user control para fazer a mesma tarefa, evitando os erros de versão. Vejam o passo-a-passo :

1) Crie um user control - referenceScrp.ascx

2) Adicione um label ao user control

3) Adicione o seguinte código ao user control :

   1: Protected Sub ToolkitScriptManager1_ResolveScriptReference(ByVal sender As Object, ByVal e As System.Web.UI.ScriptReferenceEventArgs)
   2:     Label1.Text &= Server.HtmlEncode(""" & e.Script.Name & """ assembly=""" & e.Script.Assembly & """/>") & "
"
   3: End Sub

Observe que no código não só exibimos as scriptReferences, mas para facilitar as montamos como tags asp:scriptreference

4) No evento load, faça o vínculo do evento, da seguinte forma :

   1: Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
   2:     AddHandler ScriptManager.GetCurrent(Me.Page).ResolveScriptReference, AddressOf ToolkitScriptManager1_ResolveScriptReference
   3: End Sub

5) Teste o controle. Ao inseri-lo em uma página que utiliza algum recurso de Ajax e executa-lo, verá as scriptReferences que a página utiliza, podendo utiliza-las de forma estática no scriptManager se escolher por essa opção

Veja um exemplo de scriptreferences estáticas :

   1: <asp:ScriptManagerProxy ID="ScriptManagerProxy1" runat="server">
   2: <Scripts>        
   3:     <asp:scriptreference name="AjaxControlToolkit.ExtenderBase.BaseScripts.js" assembly="AjaxControlToolkit, Version=3.0.20820.16598, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e"/>                
   4:     <asp:scriptreference name="AjaxControlToolkit.Common.Common.js" assembly="AjaxControlToolkit, Version=3.0.20820.16598, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e"/>
   5:     <asp:scriptreference name="AjaxControlToolkit.Animation.Animations.js" assembly="AjaxControlToolkit, Version=3.0.20820.16598, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e"/>
   6:     <asp:scriptreference name="AjaxControlToolkit.Compat.Timer.Timer.js" assembly="AjaxControlToolkit, Version=3.0.20820.16598, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e"/>        
   7:     <asp:scriptreference name="AjaxControlToolkit.PopupExtender.PopupBehavior.js" assembly="AjaxControlToolkit, Version=3.0.20820.16598, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e"/>
   8:     <asp:scriptreference name="AjaxControlToolkit.ValidatorCallout.ValidatorCalloutBehavior.js" assembly="AjaxControlToolkit, Version=3.0.20820.16598, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e"/>
   9:     <asp:scriptreference name="AjaxControlToolkit.Animation.AnimationBehavior.js" assembly="AjaxControlToolkit, Version=3.0.20820.16598, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e"/>        
  10:     <asp:scriptreference name="Infragistics.Web.UI.Scripts.0_igControlMain.js" assembly="Infragistics35.Web.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb"/>
  11:     <asp:scriptreference name="Infragistics.Web.UI.Scripts.2_igCollections.js" assembly="Infragistics35.Web.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb"/>
  12:     <asp:scriptreference name="Infragistics.Web.UI.Scripts.3_igUIBehaviors.js" assembly="Infragistics35.Web.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb"/>
  13:     <asp:scriptreference name="Infragistics.Web.UI.Scripts.4_igEnums.js" assembly="Infragistics35.Web.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb"/>
  14:     <asp:scriptreference name="Infragistics.Web.UI.Scripts.5_igObjects.js" assembly="Infragistics35.Web.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb"/>
  15:     <asp:scriptreference name="Infragistics.Web.UI.Scripts.7_igClientStateManager.js" assembly="Infragistics35.Web.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb"/>
  16:     <asp:scriptreference name="Infragistics.Web.UI.Scripts.8_igCallback.js" assembly="Infragistics35.Web.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb"/>
  17:     <asp:scriptreference name="Infragistics.Web.UI.Scripts.9_igPropertyManagers.js" assembly="Infragistics35.Web.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb"/>
  18:     <asp:scriptreference name="Infragistics.Web.UI.SharedScripts.igLayoutPane.js" assembly="Infragistics35.Web.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb"/>
  19:     <asp:scriptreference name="Infragistics.Web.UI.SharedScripts.igResizeBehavior.js" assembly="Infragistics35.Web.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb"/>
  20:     <asp:scriptreference name="Infragistics.Web.UI.LayoutControls.WebDialogWindow.js.igDialogWindow.js" assembly="Infragistics35.Web.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb"/>
  21: </Scripts>
  22: </asp:ScriptManagerProxy>

Observe que neste exemplo temos um scriptmanagerproxy, porque inseri esse exemplo em uma nested master page. Uma página pode ter apenas 1 scriptmanager, então nas páginas derivadas, como uma nested master page, utilizamos um scriptmanagerproxy, que nos possibilita fazer o mesmo trabalho mas na execução irá buscar o scriptmanager para executar sua tarefa

Resolve o problema, afinal todas as scriptreferences estarão lá. Porém cria outros :

1) Problemas de manutenção. Adicionar novos controles na página ou retira-los passa a exigir edição da master page.

2) Excesso de scriptreferences. Teremos na master page scriptreferences de cada controle, mesmo que estejam sendo utilizados em apenas uma página. Se tentarmos otimizar com múltiplas master pages pioramos o problema de manutenção

ScriptReference dinâmicas

Descobre-se dinamicamente as scriptreference que são utilizadas por cada página e guarda-se estas referências de forma a que quando a página estiver em cache possamos forçar as referências dinamicamente.

Falando assim até parece a solução perfeita, porém não é bem assim. A arquitetura com que os componentes se unem hoje gera vários problemas na construção desta solução :

A) O evento que nos permite identificar as scriptreferences é ResolveScriptReference. O problema é que este evento acontece após o pré-render o que nos impede de guardar informações no viewstate. Somos então obrigados a guardar informações em session ou cache, o que gera uma sobrecarga para o servidor

B) O sistema de cache parcial não considera apenas a página executada, mas também a master page. Se considerasse apenas a página, seria fácil guardarmos as scriptreferences utilizadas em cada página e posteriormente reproduzi-las. Porém, sendo o cache de cada controle vinculado com a master page, existe a possibilidade de na primeira vez que uma página for chamada alguns controles já estarem em cache e isso dificulta um pouco mais o algorítimo

Para encapsular o código e torna-lo fácil de aplicar em um site, criei uma herança do scriptManager incluindo o código para guardar as informações sobre as referência. Cada detalhe do código passou por muitos testes até chegar neste formato do algorítimo :

   1: Imports System.Web.HttpContext
   2: Imports System.Web.UI
   3:  
   4: Public Class KRScriptManager
   5:     Inherits ScriptManager
   6:  
   7:     Dim q As Queue(Of scref)
   8:     Dim modo As eModo
   9:  
  10:     Enum eModo
  11:         Indefinido = 0
  12:         enfileirando = 1
  13:         retirando = 2
  14:     End Enum
  15:  
  16:     Protected Overrides Sub OnLoad(ByVal e As System.EventArgs)
  17:         If IsNothing(Current.Session("fila" & Current.Request.Url.ToString())) Then
  18:             q = New Queue(Of scref)
  19:             Current.Session("fila" & Current.Request.Url.ToString()) = q
  20:             modo = eModo.enfileirando
  21:         Else
  22:             q = DirectCast(Current.Session("fila" & Current.Request.Url.ToString()), Queue(Of scref))
  23:             modo = eModo.retirando
  24:         End If
  25:         If modo = eModo.retirando Then
  26:             For i As Integer = 0 To q.Count - 1
  27:                 Dim scr As scref
  28:                 scr = q(i)
  29:  
  30:                 Me.Scripts.Add(New ScriptReference() With {.Name = scr.nome, .Assembly = scr.dll})
  31:             Next
  32:         End If
  33:         Dim qm As Queue(Of scref)
  34:         qm = pegarColecaoMaster(q)
  35:         For i As Integer = 0 To qm.Count - 1
  36:             Dim scr As scref
  37:             scr = qm(i)
  38:             Me.Scripts.Add(New ScriptReference() With {.Name = scr.nome, .Assembly = scr.dll})
  39:         Next
  40:         MyBase.OnLoad(e)
  41:     End Sub
  42:     Protected Overrides Sub OnResolveScriptReference(ByVal e As System.Web.UI.ScriptReferenceEventArgs)
  43:         MyBase.OnResolveScriptReference(e)
  44:         If modo = eModo.enfileirando Then
  45:             Dim sr As New scref
  46:             sr.nome = e.Script.Name
  47:             sr.dll = e.Script.Assembly
  48:             q.Enqueue(sr)
  49:             Current.Session("fila" & Current.Request.Url.ToString()) = q
  50:             guardarmaster(q)
  51:         End If
  52:     End Sub
  53:     Public Function pegarColecaoMaster(ByVal q As Queue(Of scref)) As Queue(Of scref)
  54:         Dim resultado As New Queue(Of scref)
  55:         Dim p As MasterPage
  56:         p = Me.Page.Master
  57:         Do While Not IsNothing(p)
  58:             Dim qm As Queue(Of scref)
  59:             qm = Current.Session("fila" & p.GetType.ToString)
  60:             If Not IsNothing(qm) Then
  61:                 Dim res = From y In qm _
  62:                         Where (From w In ((From z In q _
  63:                                Select z).Union(From k In resultado _
  64:                                                Select k)) _
  65:                             Where w.nome = y.nome _
  66:                             Select w).Count = 0 _
  67:                         Select y
  68:                 For Each r As scref In res
  69:                     resultado.Enqueue(r)
  70:                 Next
  71:             End If
  72:             p = p.Master
  73:         Loop
  74:         Return (resultado)
  75:     End Function
  76:     Sub guardarmaster(ByVal q As Queue(Of scref))
  77:         Dim p As MasterPage
  78:         p = Me.Page.Master
  79:         Do While Not IsNothing(p)
  80:             If IsNothing(Current.Session("fila" & p.GetType().ToString())) Then
  81:                 Current.Session("fila" & p.GetType().ToString()) = q
  82:             End If
  83:             p = p.Master
  84:         Loop
  85:     End Sub
  86: End Class
  87:  
  88: Public Class scref
  89:     Public nome As String
  90:     Public dll As String
  91: End Class

Estes dois problemas acima são solucionáveis, com um algorítimo de certa complexidade é possível criar a solução para manter as scriptreferences dinamicamente. Porém existe um terceiro problema, mais grave :

C) Alguns objetos do AjaxToolkit, tal como o rating webControl, por detalhes de seu código, dependem da ordem em que as scriptreferences são inseridas na página. Nenhuma das soluções acima - a estática ou a dinâmica - é capaz de manter a ordem das scriptReferences, consequentemente isso faz com que alguns webcontrols do toolkit - tal como o rating - simplesmente não possam ser utilizados em conjunto com o @outputcache na mesma página - em qualquer parte da página.

Conclusão

by-design O MS Ajax e o AjaxToolkit possuem incompatibilidades sérias com o @outputcache. Em um momento em que tanto se fala de scale-Out e tecnologias para isso como Azure, Velocity, ASP.NET Cache Extensibility e muito mais, ainda encontrarmos uma incompatibilidade como essa é sem dúvida grave.

O problema da compatibilidade do Ajax com o Cache está registrado no connect, mas foi declarado como sendo característica do software e não vai ser corrigido



Categories: ASP.NET , Ajax


Nome :
E-mail:
Comentarios :
 
 
Os Últimos Comentários
data: 5/26/2019 1:11:00 AM
nome: jCuaFeTcbSnY
email: rashadxzy@yahoo.com
comentário:
I'm at Liverpool University http://xnxx.in.net/freexnxx/ Free Xnxx
The customers were mainly nearing retirement and largely not experienced investors. But AXA failed to confirm how much risk its customers were prepared to take or explain the dangers in clear terms.


data: 5/26/2019 1:11:00 AM
nome: kXIOrtXyDI
email: trentone82@usa.net
comentário:
I'd like to open a personal account http://xvedio.in.net xvdios
A growing number of security firms - such as UK-basedProtection Group International (PGI) - now also offer cyberservices. PGI started out providing armed guards to protectmerchant ships against pirates but has now hired former stafffrom Britain's GCHQ eavesdropping agency.


data: 5/21/2019 6:03:00 PM
nome: WuIUjrRpOMUJRCdhLpY
email: hymangmk@gmail.com
comentário:
I do some voluntary work http://apetitmascotas.com/ nizagara side effects She has spoken directly with President Barack Obama about the reports that the United States has bugged electronic communications and institutions in Germany and elsewhere in the EU, and is sending her interior minister to Washington this week.

data: 5/21/2019 6:03:00 PM
nome: GFeulnFzgqYCTsohx
email: toneyilz@usa.net
comentário:
Could I have , please? http://egotastic.in.net egotasticallstars
Should an alien civilization come upon the Voyager 1, hopefully their own technological advancements include a record player. Loaded on board of Voyager 1 is a golden record filled with messages recorded in a variety of languages.


data: 5/21/2019 6:03:00 PM
nome: mAZITvRsErbI
email: edgardo8y@yahoo.com
comentário:
I'm a housewife http://greatlakesstudentloans.in.net my great lakes student loans From January to June, the total number of foreign visitors, including business travelers and residents, entering China declined by 5 percent to just under 13 million compared with the same period last year, according to the China National Tourism Administration. Overall, visitors from Asia, Australia, Europe and the Americas all declined.

 1  
Dicas
Dica do Dia
Receba Dicas Por Email
E-mail :  
 


 (help)
Aceito receber informativos do devASPNet, informações de eventos e treinamentos

Veja Quais Informativos Você Receberá

Pesquisar Dicas
Pesquisar Artigos, Dicas e Noticias

Banco de Dados
Algumas Entrevistas
Links Importantes

Búfalo Informática, Treinamento e Consultoria
R. Alvaro Alvim, 37/920 Centro - Cinelândia - Rio de Janeiro Cep: 20031-010
Tel : (21) 2262-1368 (21) 9240-5134 E-mail : Contato@bufaloinfo.com.br