| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | ... que o AJAX não chegava ao Gildot.
--
Your first kiss is the one from all others will be judged.
And they'll always be behind. |
| |
| | | A minha mãe já usava AJAX há uns anos... para lavar janelas! Real AJAX
|
| |
| |
|
| | Já agora, o clube foi buscar o nome a um herói grego, e possivelmente o acrónimo também não é inocente ;)
---
Omnia aliena sunt: tempus tantum nostrum est. (Séneca)
"Tudo nos é alheio: apenas o Tempo é nosso." |
| |
| | Foi recentemente disponibilizado no site DeveloperWorks um artigo sobre a utilização de AJAX com PHP, recorrendo à biblioteca SAJAX.
Why do you Linux and drive when you can BSD and fly? |
| |
| |
| | Tive o privilégio de assistir a uma apresentação sobre o tema recentemente. O assunto pode ser algo complexo, especialmente à luz do que se anda a tentar fazer actualmente com isso.
Alguns tópicos interessantes sobre o assunto:
1- SDO Service Data Objects. Pretende-se ter no cliente (browser) um mapeamento dos objectos geridos no servidor. Para além da interactividade, da maior leveza dos clientes a ideia é ter acesso aos dados na mesma "forma" que existem no cliente (implementações de AJAX que suportem SDO).
2- ActionScript com AJAX em OSS: OpenLaszlo
Penso que há um prototipo de plugin para o eclipse.
3- A macromedia tem algo equivalente ao anterior, mas não tenho aqui o link (é pago, mas têm ou vão ter plugin para o eclipse.
Cumprimentos.
|
| |
| | Para os aficionados do Perl existe, entre outros, o CGI::AJAX
CGI::Ajax - a perl-specific system for writing AJAX- or DHTML-based web applications (formerly known as the module CGI::Perljax).
"I just want you to know that, when we talk about war, we're really talking about peace." — J.W.Bush, Washington, D.C. June 18, 2002 |
| |
| |
|
| | www.ajaxpatterns.org
Este parece-me um bom ponto de partida para quem já tem as libraries e se pergunta "e agora o q faço com isto?" Já agora, o que estão a usar com PHP? (Ou estão a usar as vossas proprias libraries?)
|
| |
| | mas o javascript n funciona dentro dos .innerHMTL() :-/, em alguns browsers os forms também não !!
___________________________________ (linooks (at) zmail (dot) pt) |
| |
| |
| | Ajax não tem a ver com a propriedade .innerHTML , mas sim com a utilização da árvore DOM na construção de conteúdos. o .innerHTML é um atalho - e pouco elegante, mas todos o usam :).
Na homepage do SAPO podes ver uma utilização de carregamento de javascript usando o innerHTML (funciona em todos os browsers):
var ar = document.getElementsByName('publicidade');
for( i=0; i<ar.length; i++) ar[i].innerHTML = document.getElementById(ar[i].title).innerHTML;
O truque que usei aí foi criar no final da página os .
Outra coisa que podes fazer, é usar retorno da chamada xmlHttpRequest com código javascript e fazer o eval() do retorno.
E já agora, devia funciona sim. O Brendon Eich indicou-me já há uns meses que era um bug, provavelmnte de terem copiado o comportamento da propriedade do MSIE.
Portanto é uma questão de tempo para fazeres o que queres, apesar de haverem n alternativas. TMTOWTDI!
Cumprimentos,
Joao Goncalves
SAPO
|
| |
| | AJAX é muito porreiro sim sr, eu próprio já utilizei a "tecnologia" para algumas coisas (pequenas) e gostei. No entanto, ainda agora se começou a falar disto e já se ouve falar do aproveitamento das suas falhas de segurança (MySpace anyone ?) para fins malignos.
E também é necessário ver em que situações vale a pena ou não usar AJAX, porque também já há por aí quem diga AH FIXE AJAX A PARTIR DE AGORA SO USO ISTO MESMO NUMA SITUAÇÃO EM QUE NÃO FAÇA SENTIDO NENHUM !!!!
|
| |
| |
| | A falha de segurança em causa XSS(Cross site scripting) não é uma falha específica ao AJAX, no caso o AJAX apenas facilitou a propagação do código. A verdadeira falha está no código de filtragem de javascript que não comtemplou determinadas situações para inclusão de javascripts que são suportadas pelos browsers.
Mas sim o AJAX tem os seus problemas, essa frase que se possa dizer agora é usual em algo que é moda, lógicamente ninguem vai utilizar algo que é ligeiramente mais complexo a menos que tenho alguma vantagem em fazê-lo.
|
| |
| | Apesar de indiscutivelmente o AJAX ser muito útil, não é nem de longe nem de perto novidade nenhuma, quem está na àrea à algum tempo verá que esta moda não passa de um velho conjunto de técnicas que já se aplicavam quando lhe chamávamos DHTML. Na realidade, a única novidade é a quantidade de usos errados que reapareceram, entre eles destaco o fazer a validação de inputs do lado do cliente antes de enviar os dados em vez de o fazer do lado do servidor, o que leva como se sabe a problemas como teve o myspace (aqui o erro é do webdesigner/programador e não inerente ao AJAX em si)
ECMA Script é sempre Javascript. ;)
cumps()
---
Usem o cérebro e estarão sempre um passo à frente da inovação tecnológica.
|
| |
| |
| | AJAX não é DHTML. Penso que estás a confundir o meio com o fim. AJAX é poder invocar chamadas remotas ao servidor Web a partir de Javascript sem recarregar a página, usando uma classe de objectos chamada XMLHTTPRequest. Essa classe foi introduzida no Internet Explorer 5.5 e só vários anos depois é que o Mozilla inclui uma classe de objectos para esse mesmo propósito. A partir daí é que a coisa começou a ter interesse para muitos programadores, especialmente depois que o Gmail começou a usar este recurso para criar páginas mais interactivas em conjunto com DHTML.
|
| |
| | Eu não conheço DHTML, mas posso-te dizer que o teu exemplo de "erro" vai exactamente contra com o que tenho visto praticado em AJAX, um dos exemplos típicos é validar o input baseado em regras/código que são "carregadas" do servidor.
Além do mais a questão que referes da validação do input é um caso ominpresente nas aplicaçõesn cliente/servidor não é específico a HTTP a AJAX, lógicamente para garantir a segurança e integridade de dados a validação deve ser (em ultima instância) feita pelo servidor.
|
| |
| | Pois, para mim, sempre pensei que se devia primeiro validar no cliente APENAS para facilitar uma correcção "mais leve" e "user friendly", e tudo deveria outra vez ser validado no servidor.
Lembrem-se que o cliente é uma máquina do inimigo...
Cumps, JB .. acusaram-O de pirataria, por ter duplicado uma cesta de pão e cinco peixes, e disseram: crucifiquem-No .. (Biblia do Século XXI) |
| |
| | O facto de validares do lado do cliente não impede que valides do lado do servidor (o que deve sempre ser feito).
O que se pretende é evitar reconstruir uma página inteira (ainda que uma parte esteja em cache) só para por exemplo validar um formato de data ou uma ligação lógica entre dois campos, ou ainda reconstruir a página por não teres uma função de lookup.
Além disso, o objectivo mais vasto é teres uma mesma representação dos objectos no cliente e servidor. É bem mais vasto que o DHTML embora use o DHTML como (um dos) meio.
Cumprimentos.
|
| |
