MediaWiki Discussão:Gadget-validateBlockRollbackers.js

Tradução

Em edições como esta estão aparecendo trechos não traduzidos para o português. Ver também este tópico.

Não olhei o código, mas acho que pode ter algo a ver com esse script. Helder 14h53min de 18 de junho de 2012 (UTC)

Já tinha reparado isso quando fiz o script, mas não dei muita importância. Vou ver se ainda hoje corrijo isso. !Silent (discussão) 15h05min de 18 de junho de 2012 (UTC)

Otimizar

É mais eficiente (além de exigir menos caracteres) usar a variável local "$" (que está sendo definida com "function( $, mw, undefined )") em vez de ficar acessando a variável global "jQuery". Helder 17h58min de 20 de junho de 2012 (UTC)

Verdade. É que do nada me veio na mente isso de parar de usar o $ em casos como $.inArray, $.isFunction e etc, mas nem liguei nisso.
E com relação a esse terceiro parametro (undefined), vejo que em alguns scripts usam ele, aí resolvi por nesse também, mas não faço ideia pra serve =D Ele serve para algo ou só pra enfeitar mesmo? !Silent (discussão) 21h50min de 23 de junho de 2012 (UTC)

Parar por que?

Raramente aquele "undefined" tem utilidade. Quando tem é acho que é para evitar que o seu script (que está dentro do closure) quebre SE alguém definir uma variável chamada "undefined" E você estiver fazendo comparações do tipo "variável === undefined". No caso de quem cria plugins para o jQuery isso é importante, mas para nós é bem menos... Então eu só colocaria o undefined lá se eu estiver fazendo comparações com ele (por isso até deixei ele comentado no modelo que uso ao criar novos scripts). Helder 23h38min de 23 de junho de 2012 (UTC)

Parece que não há mais motivos para colocar aquele undefined lá. Helder 13h58min de 3 de julho de 2012 (UTC)

Uso da API

Por que estão sendo feitas chamadas síncronas à API? (isto é, com async: false e sem funções callback) Helder 17h58min de 20 de junho de 2012 (UTC)

Até hoje não entendi: qual seria exatamente a diferença entre uma requisição síncrona e assíncrona? !Silent (discussão) 18h05min de 20 de junho de 2012 (UTC)

Confesso que tive que dar uma olhada no Google para responder (pesquisei por synchronous vs asynchronous javascript). Mas segue um exemplo:

• Ative o gadget que coloca um relógio com a hora em UTC no canto da tela
• Escolha uma chamada à API que costuma demorar para ser concluída (por exemplo "action=parse" nas esplanadas)
• Abra o console do seu navegador e cole um código deste tipo:
  

  jQuery.ajax({
          url: '/w/api.php?action=parse&format=json&text={{:Wikipédia:Esplanada/propostas}}&prop=text',
          success: function() {
                  console.debug('ok');
          },
          dataType: 'json',
          async: false
  });
  

• Resultado:
  1. Com "async: false", o contador de segundos do gadget ficará parado até que a chamada seja concluída, não dá para clicar em nada na página, nem rolar para baixo/cima.
  2. Por outro lado, com "async: true" esses problemas desaparecem e dá para usar o navegador enquanto a requisição é processada. Só que assim é preciso usar funções como callback para executar a continuação do código do script.

Além disso, notei que conforme a documentação, "async: false" foi depreciado no jQuery 1.8 (ver ticket). Aqui na Wikipédia, $.fn.jquery atualmente é igual a "1.7.2", mas acho que vão atualizar para o 1.8 em breve. Helder 15h48min de 23 de junho de 2012 (UTC)

Entendi. Uma requisição síncrona é básicamente como se você estivesse carregando uma página da maneira tradicional, e nesse caso (Fazendo requisições síncronas com Ajax, que por sinal é algo meio contraditório), se o servidor não responder a página ficaria travada indefinidamente.
Mas como assim funções callback?
É algo tipo isso:

function fazAlgo() {
        return window.alert( 'Sucesso.' );
},
jQuery.ajax({
        success: fazAlgo
});

??? !Silent (discussão) 19h26min de 23 de junho de 2012 (UTC)

Isso. Nesses métodos do jQuery a função que atribuirmos à propriedade "sucess" é a callback ("function(){console.debug('ok');}" no meu exemplo, e "fazAlgo" no seu).

Parece que conforme os scripts vão ficando complexos é mais vantajoso usar uma tal de "interface Promisse" (que o Krinkle mencionou nessa alteração do software), que parece estar implementada em jQuery por meio do objeto Deferred (sobre o qual tinha visto esta descrição feita pelo Brion na lista da wikitech). Helder 20h13min de 23 de junho de 2012 (UTC)

Interessante, vou dá uma olhada nessa tal de "Promise interface". !Silent (discussão) 21h44min de 23 de junho de 2012 (UTC)

+1. O link sugerido pelo Brion parece ser um bom começo. Helder 23h38min de 23 de junho de 2012 (UTC)

Bom, no caso da primeira requisição do metódo sendMsg (Que pega os parametros do bloqueio), é fundamental que ela seja síncrona, pois senão a segunda requisição (Que envia a notificação) passa por cima, gerando coisas assim, a menos que seja colocado algo que atrase a segunda requisição. !Silent (discussão) 01h04min de 26 de junho de 2012 (UTC)

calbacks (ou depois de ter lido o link do Brion, promises... ) servem justamente para isso. o código será executado só quando tiver sido obtida a resposta da API. Helder 01h27min de 26 de junho de 2012 (UTC)

Mas o

function( data ) {
        duration      = translateDuration( data.query.logevents[ 0 ].block.duration ),
        reason        = data.query.logevents[ 0 ].comment,
         allowusertalk = data.query.logevents[ 0 ].block.flags.indexOf( 'nousertalk' ) !== -1;
}

já não é um callback? !Silent (discussão) 01h35min de 26 de junho de 2012 (UTC)

Aquilo que for colocado como success para um comando $.ajax será uma callback para aquele comando. Mas no script há duas $.ajax, e a segunda delas está sendo chamada imediatamente após a primeira, mas deveria ser chamada "de dentro" da callback da primeira, para garantir que a primeira chamada terá sido concluída antes de tentar usar o valor da "duration" na callback da segunda. Imagine que a primeira chamada demora 10 segundos par terminar e que a segunda só leva 2. No jeito que está o script, as duas requisições são feitas praticamente no mesmo instante, 2 segundo depois a segunda delas termina e vai tentar usar o valor (undefined) da variavel "duration", que só será efetivamente preenchida ao final dos 10 segundos (ou seja, tarde demais, pois aí já enviou o aviso). Helder 01h50min de 26 de junho de 2012 (UTC)

Veja por exemplo como tive que "encadear" as três callbacks do MediaWiki:Gadget-NewVillagePump.js/Core.js (procure por "callback: function(){" e encontrará as três). Helder 01h54min de 26 de junho de 2012 (UTC)

Resolvi dá uma olhada no objeto Deferred, e descobri que existem os metódos when e then, que servem justamente para o que eu quero, o problema é que não funciona, dá undefined do mesmo jeito a não ser que eu execute pelo console (Mas dessa forma a versão anterior também funciona, não sei como). Então acho que o único jeito é encadeando as requisições mesmo. !Silent (discussão) 12h44min de 26 de junho de 2012 (UTC)

Apesar de eu ter lido a respeito do when e do then, ainda não pude fazer nenhum teste com isso. Já tentou definir uns pontos de interrupção no console do chrome ou no firebug para ver o que está occorrendo quando essa parte do código é executada? Talvez ajude... Helder 16h02min de 26 de junho de 2012 (UTC)

Veja como o when foi usado para implementar essas promessas na MediaWiki:Gadget-NewVillagePump.js/Core.js. Helder 02h24min de 22 de julho de 2012 (UTC)

O script não mais selecionando o motivo do bloqueio automáticamente

Ao invés disso, o motivo fica setado como "Outros", o que não faz sentido. Porém, se colocar dessa forma:

$( '#mw-input-wpReason' ).find( 'option' ).eq( 1 ).attr( 'selected', true );

funciona normalmente, sendo que o jeito anterior também (em tese) é válido. !Silent (discussão) 20h13min de 11 de outubro de 2012 (UTC)