A história do ASP 3.0

Postado em 11. out, 2009 por Chiavegatti.

A tecnologia ASP nos permite gerar conteúdo neutro para o browser cliente usando scripts no lado-servidor (server-side) dinamicamente.

O código que acompanham estes scripts podem ser escritos em quaisquer idiomas e embutidos em Tags especiais dentro do HTML tradicional, em arquivos de inclusão para simular um (Code-behind) ou cima de todo o conteúdo HTML.

Este script é heterogêneo , sendo que a página quem o cotem é apenas interpretada pelo servidor de rede no momento que é executada a requisição no lado cliente.
O ASP clássico não é compilado é interpretado! (por isso ame-o ou deixe-o!)

Para entender a evolução e surgimento do ASP e suas capacidades,é preciso saber um pouco da história de aplicações voltadas para web…

A internet estática

Nos primórdios da web toda a informação era provida diretamente ao Browser do cliente e por sua vez era completamente estática.

Sendo que todo conteúdo requistado pelo cliente “A” no web-server seria exatamente igual ao requistado pelo cliente “B”.

O web-server não gerava absolutamente nenhuma parte do conteúdo de forma dinâmica, executando apenas a requisição do http do documento nele armazenado, hospedado , hosteado, guardado…

Ele ( o web-server) recebia a requisição e entregava integralmente o documento ao Browser cliente.

Não existindo assim nenhum laço de interatividade entre o cliente e o servidor.

Embora a evolução atual da web seja fantástica, mesmo naquela época sua evolução era na velocidade da luz, rapidamente as páginas estáticas evoluíram, tendo imagens e sons (mesmo que mids nojentos) mas eram sons!.Mesmo que caveirinhas piscando (mas eram imagens!)

Apesar disso ela continuava estática e com pouca interatividade, e fracamente funcional podendo apenas prover links e mais links….

A internet Dinâmica…engatinhando! Aplicações CGI

Uma das primeiras extensões da internet estática foi o CGI (common Gateway Interface), o CGI então provia o mecanismo no qual o Browser cliente poderia enviar uma requisição de excussão de aplicação ao web-server . Então o resultado dessa aplicação seria convertido e formatado em HTML legível pelo Browser cliente, a CGI foi rapidamente incorporada para efetiva utilização na world wide web(www), sendo ela um caminho fácil para compartilhar informações viabilizando uma plataforma de processamento de dados (server-side)….

A resposta para essa considerável evolução na web, foi o rápido e crescente interesse em si desenvolver aplicações comerciais na web pelo paralelo mundo empresarial.

Diante desse interesse $$ começou a era da criação de scripts client-side, que permitiam ao cliente (browser) assumir parte das tarefas de processamento. Então começou a explodir soluções client-side mundo à fora, nascendo assim o javascript da finada Netscape e o VBScript da onipresente Microsoft.

E nesse período como não podia deixar de ser… Tio Bill sagaz e perneta! Liberou a sua primeira versão do IIS (internet information server), o que seria de fácil utilização, escalonável, portátil, seguro(?) e totalmente integrado ao também finado Windows NT. Tornando-se um (“webserver”) popular com rapidez astronômica…

A internet Dinâmica…querendo falar ! Aplicações ISAPI

Além de apoiar, bajular e aplaudir as especificações da CGI, a Microsoft apresentou uma alternativa à CGI, denominada Internet Server Application Programming Interface (ISAPI). Resumidamente o ISAPI iria suprir uma limitação do CGI que toda vez que o cliente requisitava a execução de uma aplicação CGI, o web-server executava uma instância da aplicação CGI, em seguida enviava ao Browser cliente a informação requisitada, proveniente do resultado da aplicação CGI que era finalmente processada no Cliente.

Mas esse processo de trabalhar instâncias da CGI teria um preço um pouco alto, cada requisição a CGI era instanciada.Uma nova CGI criada era instânciada e assim sucessivamente e novamente, e novamente e novamente, Com isso o pomposo Server ia miando, ia miando….miando…e miando….Até mijar no dedão e travar.

A CGI tinha o poder de sugar o web-server ( na época com recursos muito pequenos diga-se de passagem) , vampirizando os recursos do servidor de modo silencioso.

O ISAPI aliviava esse problema porque relacionava os processos em (DLLs) (dynamic link libraries) Cada aplicação ISAPI em forma de uma simples dll era carregada em um espaço de memória no web-server, imediatamente na primeira requisição de processo de execução do aplicativo.

Uma vez lá !(na memória), a DLL continuaria lá e lá ficaria enquanto o usuário (browser -cliente) permanecesse executando pedidos e só seria descarregada de lá (da memória) com um pedido explícito (..Tipo: Vamos sai daí já!).
Isto aumentou a performance e otimizou a tarefa de gerenciamento da memória. Todo o ISAPI DLLs deve estar em um thread seguro de forma que as múltiplas linhas podem ser instanciadas na DLL sem causar problemas com a função da aplicação atual ou standby.

As aplicações de ISAPI normalmente são mais rápidas que as aplicações de CGI equivalentes porque o web-server não tem que instanciar uma aplicação nova toda vez que um pedido era feito. Uma vez a aplicação de ISAPI DLL está na memória, ela fica na memória. E o web-server não precisa carregá-la novamente.

Além de aplicações de ISAPI, o ISAPI permitiu a criação de filtros ISAPI.

Um filtro ISAPI é nada mais do que uma DLL customizada que está no mesmo espaço de memória web-server e é chamado pelo web-server em resposta a todo http requisitado. Em deste modo, o filtro ISAPI trata as mudanças e a maneira na qual o próprio web-server irá se comporta.
Os filtros ISAPI então instruem o web-server como controlar as requisições. Os filtros ISAPI permitem personalizar a resposta de um web-server para tipos específicos de requisições dos Clientes.
Para diferenciar um filtro ISAPI e aplicações de ISAPI (e aplicações de CGI)de maneira mais clara, um filtro ISAPI oferece três tipos de funcionalidade que os separa de uma aplicação ISAPI (ou CGI):

Um filtro de ISAPI permite a você fornecer uma form no seu site ou uma página segura através de inserção em uma camada entre o cliente e o web-server.

Um filtro de ISAPI permite a você localizar mais informação sobre as requisições ao web-server e o conteúdo provido por quem o requisita um documento sobre o HTTP padrão ao web-server. Estas informações são armazenadas separadamente em outro formato de arquivos, txt na maioria das vezes, criando um Logging das funções do web-server

Um filtro de ISAPI fornecia informação aos clientes de uma maneira diferente que o web-server pode por si só não poderia fazer.

Aqui são alguns do filtros de ISAPI:

Uma camada Segura entre o cliente e o web-server (SSL). Esta camada de segurança pode prover para uma blindagem mais completa durante a requisição pelo cliente e possibilitou a utilização de Login e senha, criando ambientes de autenticação.

Um filtro ISAPI customizado, pode interpretar o fluxo de informações do servidor e, baseado naquela interpretação, apresentar o fluxo de texto em um formato diferente daquele que web-server possui originalmente.
O ASP.DLL é um exemplo deste tipo de filtro de ISAPI. Interpreta o código do servidor em um manuscrito requisitado pelo cliente e, dependendo de sua interpretação, provê ao cliente um conteúdo personalizado de acordo com sua requisição.

Um filtro ISAPI customizado pode traçar a requisição de um cliente a um local físico diferente no servidor.
Isto poderia ser usado em locais e volumes de alta capacidade onde você poderia querer movimentar o cliente sobre um servidor diferente.

Um filtro ISAPI desenvolvido de maneira profissional pode originar novas formas ou até linguagens de programação para web.

A internet Dinâmica… Voando baixo

Nos mirrados anos do IIS 2.0, a Microsoft começou a testar o beta de uma tecnologia com o codinome Daneli (a Microsoft adora batizar seus betas com codinomes), hoje chamamos essa tecnologia de ASP – Active Server Pages isso foi um marco na estratégia da Microsoft de alavancar o IIS 2.0. O ASP é encapsulada dentro um único e pequeno arquivo dll de (~300K) chamado ASP.DLL.

Esta DLL é um filtro de ISAPI que reside no mesmo espaço de memória do IIS. Sempre que um usuário pede um arquivo cuja extensão é. ASP, o (ASP filtro ISAPI) criam as instâncias de interpretação.

O ASP carrega qualquer linguagem de criação de scripts que possam ser interpretadas pelas DLLs na memória, executa qualquer código server-side encontrado na página ASP, e passa esse resultado para um HTML, isso ainda no lado servidor, então envia isto ao Browser – Cliente (Client- side).

Só para reafirmar, a produto ASP gerando no servidor é puramente HTML ou um conjundo de códigos cliente-side que são ou já estão inseridos no fluxo de texto que o Browser – Cliente enviou…

Então para finalizar….

O ASP não surgiu para tapar buracos, é apenas mais um filtro, não veio para fazer coisas extraordinárias, veio de uma cronologia evolutiva normal e obrigatória como todo e qualquer sistema ou linguagem, e dele agora temos o ASP.Net que na teoria seria a evolução do ASP, faz o que o ASP faz e ainda lava, passa, cozinha, e assa 500 mil lingüiças em segundos!

Continue Lendo

Como o Ajax funciona

Postado em 10. out, 2009 por Chiavegatti.

Na linguagem javascript tradicional, quando você quer pegar alguma informação do banco de dados ou arquivo que está lá no servidor, ou então enviar alguma informação para o servidor, você precisar criar um formulário HTML e trabalhar com os métodos GET ou POST para pegar (get) ou enviar (post) dados para o servidor.

O usuário por sua vez, normalmente deve clicar no botão enviar para pegar ou enviar informações, esperar o servidor responder a requisição, e carregar a nova página com os resultados.
Por retornar uma nova página a cada vez que o usuário envia o formulário, as aplicações web tradicionais costumam ser lentas e pouco amigáveis, executando o re-carregamento da página a cada envio.
Com o Ajax, o Javascript é quem se comunica diretamente com o servidor, através do objeto XMLHttpRequest.

Com o HTTP request, a página web fica habilitada a fazer as requisições ao servidor, obter e enviar dados sem a necesidade de re-carregamento da página. O Usuário por sua vez permanece sempre na mesma página.

O usuário envia a requisição que deve ser executada e a resposta será exivida em uma camada identificada por um ID, sem recarregamento total da página em que o usuário está. Por exemplo uma div com o seguinte ID:

<div id="respostaAjax"></div>
A seguir você confere os próximos passos de como criar um objeto XMLHttpRequest e receber uma resposta do servidor.

1. Criando o objeto XMLHttpRequest

Browsers diferentes utilizam métodos diferentes para criar uma objeto XMHttpRequest. O Internet Explorer por explo usa o ActiveXObject, enquanto outros Browsers usam o objeto XMLHttpRequest.

Para criar este objeto, e para que ele funcione em todos os browsers, vamos trabalhar com um controle condicional conhecido como “try and catch”.

function ajaxFuncion()

{
var xmlHttp;
  try
{
// Opera 8.x , Firefox, Safari
xmlHttp = new XMLHttpRequest();
 }
catch(e)
 {
// Internet Explorer
try
{
xmlHttp=new ActiveXObject(”Msxml2.XMLHTTP”);
}
catch (e)
{
try
{
xmlHttp=new ActiveXObject(”Microsoft.XMLHTTP”);
}
catch (e)
{
alert(“Seu browser não suporta Ajax!”);
return false;
}
}
}

2. Envie uma requisição ao servidor.

Para enviar a requisição ao servidor usaremos dois métodos o open() e o send() .

O Método open() recebe normalmente 3 argumentos. O primeiro rgumento define qual o método usuaremos para enviar os dados ao servidor, se será pelo GET ou POST. O segundo argumento define qual é a página com script server-side que iremos usar para consumir a informação que queremos e o terceiro argumento define se iremos manipular os dados de forma assíncrona.

O método send() por usa vez envia a requisição ao servidor.

1
2

xmlHttpRequest.open(“GET”,”horas.asp”,true);
xmlHttpRequest.send(null);

3. Escrevendo o script server-side.

O método responseText armazena a informação retornada do servidor. No caso estamos aguadando o retorno de uma página asp que nos fornece a hora atual. o Código que a página asp deve conter é o seguinte:

1
2
3
4

<%
response.expires = now –999
response.write (time)
%>

4. Consumindo a resposta

Agora iremos consumir a resposta do servidor e exibir a informação para o usuário.

1
2
3
4
5
6
7
8
9

xmlHttp.onreadystatechange=function()
{
if(xmlHttp.readyState==4){
document.myForm.time.value=xmlHttp.responseText;
}
}
xmlHttp.open(”GET”,”horas.asp”,true);
xmlHttp.send(null);
}

Continue Lendo