07th abr 2009
O POG nosso de cada dia #3
Talvez esse seja, dos POGs, o menos feio de se aplicar que eu já vi.
Quem desenvolve em javascript e já utilizou qualquer tipo de requisição assíncrona ao servidor, seja ela feita com frameworks como jQuery (por exemplo com o método load()), Prototype (usando o objeto Ajax) ou mesmo feito a requisição na mão (com o objeto XMLHttpRequest) certamente teve problemas com cache no retorno dos dados no Internet Explorer.
Código Original
Usando a jQuery, imagine o seguinte request:
$(“myElement”).load(“minhaurl.htm”);
O problema
Acontece que os IEs (não sei na versão 
o resultado de qualquer requisição assíncrona é cacheado. Então, se o conteúdo de minhaurl.htm for alterado, isso não refletirá no response.
Solução bonita
Abandonar os IEs. Mas, isso não vai acontecer mesmo…
POG
A solução que eu encontrei, anos atrás, foi passar um valor randômico como parâmetro pela url, usando o método random() do objeto Math.
$(“myElement”).load(“minhaurl.htm?rnd=” + Math.random());
É estranho ter que gerar esse random para todas as requisições, mas a limitação imposta pelo browser é mais forte 
Posts relacionados
Avalie
(No Ratings Yet)
Uhn
Penso que isso seja uma POG mais do navegador do que do desenvolvedor.
Afinal, ele teve que fazer isso pra contornar um problema do navegador e não algum problema na codificação.
Isso não é tão POG assim. Só não é a solução mais bonita… Malditos navegadores (suponha aqui que IE é navegador). E olha que já vi coisas bem piores pro mesmo problema
Pow, então, eu mesmo concordo que não seja O pog esse e tal, mas o simples fato de ter que escrever mais código sem a necessidade real, torna a solução bizarra.
Mas, como falei, culpa do navegador :-/
Que Deus tenha pena da alma de quem programou o IE…
velhão, pog é o que nego faz aqui no trampo… da ate desanimo faze as coisas bonitas!
esses dias foi criado 32 classes(css) iguais pra um loop em php….
eu nem falo mais nada =/
é.. é foda isso.. eu uso o timestamp ao invés de gerar um random.
[]s
Boa solução essa do timestamp. Faz até mais sentido, pois pega a data atual do cliente que dificilmente vai se repetir… só se ele mudar o relógio! hehe
Tenho até vergonha pela pessoa quando ela chama esse Recurso Tecnológico Alternativo de gambiarra!
abraço
POG é o que eu faço com o img cache bug no IE: http://groups.google.com/group/arqhp/browse_thread/thread/5c339bd56dce1400/9f8cc9570d104aa3
Carrego todas elas numa div oculta…
O chamado “workaround”!
É verdade… Esse ‘erro’ é um saco!
Também uso timestamp
‘noCache=’ + (new Date()).getTime()
[]’s
Timestamp na cabeça! Até porque esse valor aleatório não tem e nem nunca terá sentido algum, já o timestamp pelo menos identifica quando a ação ocorreu, precisando no futuro já estará lá!
Cara, mas o timestamp gerado no cliente também não faz muito sentido… se é pra saber quando a ação ocorreu, tem que ser a hora do servidor……
Pode não fazer sentido para nós Chris, mas para o cliente provavelmente fará. Pense num daqueles campos que avisam quando foi feita a última alteração, tão comuns em web apps por aí, e você vai perceber que para o cliente faz mais sentido que a hora que apareça ali seja a dele, mesmo que errada, pois o erro é sempre no mesmo sentido para ele.
É tudo uma questão de contexto…
Mesmo assim, não faz sentido… a última alteração é uma informação que deve ser guardada no servidor – até mesmo para traçar uma auditoria futura, se necessária.
Agora, se você vai guardar essa informação no cookie e usá-la depois, beleza, poderia até ser. Mas para o lado do servidor, continua não fazendo sentido ao meu ver…
Concordo com o @chrisloki. Realmente a data do ciente não faz sentido em caso de controle. Visto que nem sempre é confiavel.
Utilizo o timestamp mais por opção. Não uso o RANDOM pq n tenho controle sobre ele (coisa de maluco) mas acredito não ter problema em relação a utilização.
O timestamp é incremental e único sempre! Esse é o principal motivo de minha escolha.
Enfim, os 2 recursos estão lá prontos, basta escolher, hehehe.
[]’s
Sobre controle de data, é indiscutível a utilização da data do SERVER, por ser uma data confiavel.
O Cliente pode estar com uma data/hora totalmente errada se perceber (imagina 01/02/2001, para um sistema q foi lançado ontem, rsrs).
Enfim. Na minha opinião nada de data do cliente para controle.
[]’s
Corretíssimo Chris, para o servidor realmente não faz sentido algum!
E eu nem estava falando de guardar a informação, me referia a besteiras do tipo: (Último Rascunho salvo às 15:03) que só fazem sentido para o cliente se a hora que aparecer for a do relógio dele e que só são relevantes durante a duração da sessão.
A confusão aqui é que eu estou falando de feedback em tempo real para o usuário e vocês estão falando de controle no servidor…
Não vamos começar uma discussão em torno disso: você gosta de torradas da Bauducco e eu prefiro as feitas em casa, cada um com seus gostos!
Concordo 100% contigo. Na minha opinião também: nada de data do cliente para controle.
Mas para dar o feedback ao cliente, durante a sessão, a hora tem que ser a dele, mesmo que errada(lembrando que para o cliente 15:12 de 01/02/2001 vai vir depois de 15:03 de 01/02/2001 mesmo que na verdade sejam 11:29 de 08/04/2009 !) porque senão corremos o risco de deixá-lo confuso…
Pois é… huahuahuahuhuaa
Realmente é uma situação esquisita.
Mas sinceramente, ainda acho errado! Vou explicar meu ponto de vista…
Controle de data:
Se for para algum tipo de controle (cookie q seja) necessário para um JS e tal, BLZ! O ideal é utilizar a data do cliente msm.
Visualização de datas/hora para o cliente:
Cara, se o cliente está com a data errada
o problema é dele!(não necessariamente com essas palavras, hehe.)O sistema/site deve manter concistência! Quem sabe não sirva até como uma dica para o cara.
Imagina se o cara descobre de alguma outra forma que a data da máquina dele está errada, vai dizer que o seu site é maluco pq também mostra a data errada, rsrsrs.
…
Enfim, eu voto na consistência do seu servidor!
[]’s
Eu voto na opção que apresentar a maior usabilidade para o usuário, o cliente em primeiro lugar!
De quê que adianta, para o usuário, a hora naquele exemplo do “Último Rascunho salvo às” se ele não tiver como relacionar esta informação com a que é mostrada no relógio do computador dele?
Eu acho que essa discussão toda da data do servidor X cliente para apresentar dados para ele, vai gerar uma enquete por aqui! hehe
Antes do meu próximo comentário, isso não seria assunto para outro post??? rsrsrs
Só para constar…
Acabei de testar no GMail e ele pega a hora do usuário!
Mudei a data do windows para testar.
[]’s
Era disso que eu estava falando!
Imagino que o povo do Google tenha seguido este mesmo raciocínio…
Para mim (e para os meus clientes) faz todo o sentido!
[]s
Eu sou muito contra usar qualquer informação da máquina do usuário: cookie, data/hora, etc…
Mas, é questão de gosto, acho! hehe
Também acho! Por isso que falei das bolachas!
[...] #3: cache em requisições assíncronas por javascript [...]