[Gastosabertos-dev] ao
Andres MRM
andres em inventati.org
Sexta Março 6 19:16:18 UTC 2015
Tive o mesmo tipo de erro (a tabela não abriu).
Pelo que vi nos logs está dando: 'Lost connection to MySQL server during
query'
https://gist.github.com/andresmrm/3e2ac724d5c491607f09
Tem vários parecidos com esses lá.
Aparentemente o pau é na hora de 'X-Total-Count': revenue_data.count()
Será que é dado demais para ele contar? =P
Outra coisa, Luiz, o pubsub é para estar funcionado?
Estou abrindo, por exemplo:
http://site.gastosabertos.org/receitas/?year=2014&level=2.3#2014/1?page=3&year=2012&level=2.3
Indo no console e dando:
pubsub.publish('years:changed', {value: [2012]})
Mas ele está retornando 'false'
Apertar os botões da tabela, apesar de fazer duas requisições que retornam 200
OK, não está tendo efeito...
Aumentar o número de páginas da tabela também faz as requisições, mas não
altera nada na página...
Quoting Luiz Armesto (2015-03-04 13:43:11)
> Aconteceu aqui o problema de não carregar a tabela direito mas com uma causa
> diferente das possibilidades levantadas. No caso o servidor da api deu erro
> 500.
>
> Não consegui reproduzir o erro nem localmente nem no próprio servidor (dando
> reload ou abrindo em outra aba o mesmo endereço da api, com os mesmos
> parâmetros. funcionou).
> Precisaria ter acesso ao log do servidor para ver o que houve.
>
>
> []'s
>
> 2015-03-02 23:05 GMT-03:00 Luiz Armesto <luiz.armesto em gmail.com>:
>
> 2015-03-02 22:04 GMT-03:00 Edgar Zanella Alvarenga <e em vaz.io>:
>
> Ok, vi com mais calma o código agora e seu email esclareceu melhor
> alguns pontos. Estava confuso com os eventos 'page.dt' e 'length.dt',
> não sabia que eram eventos do próprio DataTables e pensei que os
> tinha criado também.
>
>
> É, isso não estava claro mesmo.
>
>
>
> Gostei de como fez, só acho que da linha 85 a 114 ficou um pouco
> obfuscated, apesar de entender a razão de querer ter feito um código
> genéricopra lista de parâmetros em 'param'. Acho que seria melhor
> ter um subscribe explícito por parâmetro e separar em funções distintas
> cada uma das cláusulas condicionais entre 103 e 107, entende, ao
> invése de um setParam genérico.
>
>
> Sobre as clausulas no setParam eu cheguei a fazer separado, mas acabei
> juntando justamente para aprovitar o código de "subscribe" genérico (linhas
> 85-114).
>
> Acho que separar os "subscribe" em dois explícitos para "page" e
> "per_page_num" e um genérico (o atual) não teria problema, apesar de
> introduzir código parcialmente repetido, mas se melhora a leitura e
> compreensão vale a pena.
> O que não dá é para remover completamente o código genérico que itera nas
> chaves dos parâmetros definidos na inicialização do objeto senão ele deixa
> de ser reaproveitável. Ficou um tanto obscuro mesmo, mas posso melhorar com
> um comentário explicando o que o trecho faz e o porquê.
>
>
> Isso deixaria mais claro o código e mais separado a lógica a ser
> realizada a cada mudança de parâmetro.
>
> Tirando isso, maravilha, acho legal irmos por esse direção, me parece
> uma solução simples e elegante.
>
> Quanto a dependência com o jquery, sim, devemos colocar isso via
> require,
> a idéia é que todo gerenciamento de dependência deja feito por ele,
> então considere esses imports via script como algo que vamos ter
> que resolver.
>
>
> blz
>
>
>
> Ah sim, o parâmetro code pro endpoint listrevenue já está funcionando:
>
> http://demo.gastosabertos.org/api/v1/receita/list?code=1.1.2&page=0&
> per_page_num=10&years=2014
>
> Basta adicionar o code com parte do nível superior cujo subníveis quer
> consultar.
>
>
> Boa, já inclui na tabela.
>
>
>
> E pra finalizar, sobre o Riot, eu só tinha visto o observer dele, mas
> nunca usei e não faço idéia se na prática ele iria nos ajudar ou
> complicar
> mais no nosso caso de uso, pelo menos no problema de sincronização de
> eventos. Eu só fiquei pensando se não era algo já resolvido por um
> desses frameworks da modinha ou libs simples como:
>
> https://github.com/mroderick/PubSubJS
> https://github.com/uxder/Radio
>
> Que talvez evitem que tenhamos muito trabalho em resolver problemas que
> não são nossa prioridade no momento. Novamente, não conheço a fundo
> nenhuma dessa libs que citei e a única vantagem que vejo nelas é
> estarem
> desacopladas do JQuery, caso fossemos pra uma solução JQuery free.
>
>
> Vou ver essas libs, mas de qualquer modo estou usando o jQuery para pub/sub
> com facade, entre outras coisas, para usar uma interface com nomes de
> métodos comuns a implementações de pub/sub, então se quisermos chutar o
> jQuery e usar uma lib dedicada será bem tranquilo. Ou adaptamos a facade
> para a nova lib ou, se a interface for a mesma que fiz, tiramos a facade e
> usamos direto a lib.
>
>
>
> Mas entendo o ponto de que estamos tentando sincronizar componentes de
> libs diferentes, com arquiteturas diferentes e no final se fossemos pra
> uma solução "mágica" acabaríamos tendo que fazer vários códigos ao
> redor
> dessas bibliotecas pra conversarem entre si. E fiquei pensando na parte
> pra sincronizar as mudanças nas variáveis com alterações no URL,
> leitura
> do URL pros parâmetros nas diferentes visualizações e me perguntei se
> não tinha uma solução onde ganharíamos tudo isso pronto de lambuja (a
> man
> can dream!).
>
>
> Já enviei o código que estava fazendo em relação a URL usando hash e o pub/
> sub. Se tudo deu certo ao acessar http://site.gastosabertos.org/receitas/#
> 2014/1.1.1?page=7 (e não estiver usando o js velho salvo no cache do
> navegador) verá a lista exibindo a página 8 dos impostos de 2014. Se
> navegar pelas páginas da tabela a URL deve ser atualizada e se usar os
> botões de back/forward do navegador a tabela deve se atualizar junto com a
> URL. Editar manualmente o ano (para periodo use hifen para separar o ano de
> inicio e de fim) e o código na URL também funciona.
>
>
>
> Enfim, acho uma boa irmos pela direção que tomou, só talvez tornar isso
> mais independente para que seja replicado nas outras páginas,
> provavelmente
> fazendo uma biblioteca, RSpubsub (Really Simple PubSub), mas esse não
> precisa
> ser nossa prioridade agora.
>
> Abs,
> E.
>
>
> []'s
>
>
>
> On 02/03/2015 19:27, Luiz Armesto wrote:
>
> 2015-03-02 17:30 GMT-03:00 Edgar Zanella Alvarenga <e em vaz.io [39]>:
>
>
> Oi Luiz, ótimo! Dei uma olhada rápida no seu código e fiz
> alguns
> testes.
> Está legal, mas ocorreu mais de uma vez ao visitar o
> http://site.gastosabertos.org/receita [1]
>
> que o gráfico drilldown carregou, mas a tabela não. Uma vez
> consegui identificar
> o erro, que foi não conseguir importar o Datatables, talvez o
> servidor deles
> estava fora do ar.
>
>
> Vou verificar isso. Além de problema no servidor deles pode ter
> sido
> timeout do requirejs ou talvez tentou carregar o datatables antes
> do
> jquery (atualmente o jquery está sendo carregado direto no html,
> com
> tag script, mas o datatables via requirejs. Isso porque o jquery já
> estava sendo usado direto sem o requirejs e o datatables identifica
> se
> tem alguma lib de AMD, no caso o requirejs, e se registra direto
> nela,
> não deixando carregar colocando direto uma tag script com ele,
> então
> tive que carregar usando o requirejs. Precisamos arrumar isso, ou
> usar
> requirejs ou não usar, misturar é pedir problemas).
>
>
>
>
> Mas olhando seu código, fiquei encafifado com a quantidade de
> código
> que escreveu pra registrar os eventos e não ficou claro pra mim
> o
> quão
> fácil será fazer isso sincronizado com o gráfico de barras. Se
> tivermos
> uma forma fácil de utilizar o modelo pusub que está usando
> legal
> sem muito
> biolerplate code, ótimo. Mas fico em dúvida se utilizarmos uma
> solução
> como o Riot js não seja melhor, pra não termos que resolver
> novamente
> certos problemas.
>
>
> O que você acha? Por mim sem problemas
>
>
> s em uma mesma página. O quanto
> de código precisará ser replicado? Se conseguir fazer um resumo
> bem breve
> do que tem em mente pra anotar os eventos e criar as funções
> pra
> respondê-los
> seria legal.
>
> Pelo que olhei no riotjs não enxerguei uma solução mais simples
> usando ele do que a que pensei. Nós temos que integrar
> componentes
> que são feitos com lib
>
> s, então para sincronizar temos que escutar os eventos que essas
> libs
> emitem quando o usuário interage com elas e chamar métodos que elas
> definem na API para alterar seus valores na hora de sincronizar.
> Não
> vejo como as funcionalidades do riotjs de virtual DOM com
> interpolação (o DOM que exibem os gráficos e as tabelas são
> criadas pelas próprias libs externas, não temos controle sobre
> isso)
> podem ajudar.
>
> O que poderiamos usar do riotjs é a API de Observer deles, mas o
> jQuery já implementa isso (é o que estou usando) e já o temos como
> dependência.
>
> Vocês chegaram a pensar em como sincronizar os vários componentes
> usando o riotjs e viram usos dele que eu não enxerguei?
>
> Sobre a implementação do Sub/Pub, na verdade é apenas uma facade
> para a implementação de eventos do jQuery, são 7 linhas [0] que
> definem um objeto e redirecionam 3 métodos para o jQuery:
>
> subscribe --> on
> unsubscribe --> off
> publish -- trigger
>
> Para usar é simplesmente criar uma instância e se registrar com o
> "subscribe" para receber as notificações de uma determinada
> mensagem
> e mandar notificações com o "publish":
>
> // Cria o objeto
> var pubSub = new PubSub();
>
> // Registra para receber notificações
> pubSub.subscribe(nome_da_mensagem, function(evt, content) {
> console.log(Mensagem recebida com o seguinte conteúdo: ,
> content);
> });
>
> // Publica notificação
> pubSub.publish(nome_da_mensagem, este é o conteúdo);
>
>
> // Neste ponto foi exibido "Mensagem recebida com o seguinte
> conteúdo: este é o conteúdo"
>
> Então para usar o pub/sub é bem fácil e com muito pouco código,
> só precisa que todos os envolvidos na sincronização tenham acesso
> ao mesmo objeto de pub/sub e compartilhem de uma padronização nos
> nomes e formatos das mensagens enviadas, sem ter conhecimento de
> quem
> são os demais participantes (desacoplados). Então se, por exemplo,
> a
> tabela registrou para receber uma mensagem quando o código é
> alterado, ela tera o mesmo comportamento independente se a
> alteração
> é proveniente de uma mudança na url, um clique no gráfico ou uma
> seleção num menu, só precisa que a mensagem seja publicada no
> objeto pub/sub seguindo o padrão definido.
>
> O que acontece, em relação a quantidade de código que escrevi, para
> ter mais linhas [1] do que 3 simples "pubSub.subscribe(...)" (que
> seria um para "page", um para "per_page_num" e um para "years", que
> são as três coisas que atualmente importam para a tabela) é porque
> eu fiz de um modo que o mesmo objeto pode ser reutilizado para
> tabelas
> diferentes, que buscam os dados em outros endpoints que tenham
> parâmetros diferentes (ou mesmo para estender o funcionamento da
> tabela atual quando os outros parâmetros forem implementados, como
> o
> "codes", sem precisar alterar o código).
>
> Eu defino na criação do objeto quais são os parâmetros do endpoint
> que importam para a tabela, ou que poderão ser alterados
> externamente
> por outro componente, podendo definir um valor inicial [2], então
> eu
> itero sobre os parâmetros registrando automaticamente [3].
>
> Assim, se eu criar um objeto DataTable passando nas opções "params:
> { years: 2014, page: 0, per_page_num: 10 }" ele vai se registrar
> para as mensagens "years:changed", "page:changed" e
> "per_page_num:changed" e quando qualquer um publicar uma dessas
> mensagens ele vai se atualizar. Quando tivermos implementado o
> parâmetro "codes" na endpoint "List revenues" basta alterar na
> criação do objetos incluindo esse parâmetro nas opções (passando
> a ser "params: { years: 2014, page: 0, per_page_num: 10 , codes:
> null
> }") que a tabela passará a responder também a mensagem
> "codes:changed", armazenando internamente o valor (método
> "setParam"
> chamado pelo callback do "pubSub.subscribe"), que será enviado na
> requisição AJAX (no método "_ajaxRequest", que é usado pela lib
> DataTables, e é responsável por enviar todos os parâmetros
> registrados).
>
> Então para criar tabelas com dados diferentes, endpoint diferente e
> parâmetros diferentes, mas também facilmente sincronizável e com
> paginação via ajax, basta criar um objeto DataTable informando qual
> a url do endpoint, quais são os parametros e quais são os campos do
> json de cada coluna e pronto. Fazer o que está entre as linhas 199
> e
> 222 [4] com as devidas alterações, em especial em "columns" e
> "params", sem precisar nem criar mais funções nem definir outros
> tipos de objetos.
>
> TL; DR;
>
> Para sincronizar, o componente com o qual o usuário está
> interagindo, por exemplo no caso do ano ser alterado, só terá que
> chamar "pubSub.publish(years:changed, {value: [anoMin, anoMax]})" e
> os
> demais terem se registrado com "pubSub.subscribe(years:changed,
> callback)", e implementado a logica necessária no callback, para
> serem notificados e se manterem sincronizados.
>
> O DataTable é mais complicado do que isso pois foi feito de modo
> genérico para ser reutilizado em outras páginas, pecisando apenas
> configurar algumas coisas na criação do objeto.
>
>
> [0] https://github.com/okfn-brasil/gastos_abertos_website/blob/
> cd83cc446e6953b2281c7cebbdabc8f7d5e79772/frontend/src/javascripts/
> receitas/main.js#L188
> [40]
>
> [1] https://github.com/okfn-brasil/gastos_abertos_website/blob/
> cd83cc446e6953b2281c7cebbdabc8f7d5e79772/frontend/src/javascripts/
> receitas/main.js#L71
> [41]
>
> [2] https://github.com/okfn-brasil/gastos_abertos_website/blob/
> cd83cc446e6953b2281c7cebbdabc8f7d5e79772/frontend/src/javascripts/
> receitas/main.js#L211
> [42]
>
> [3] https://github.com/okfn-brasil/gastos_abertos_website/blob/
> cd83cc446e6953b2281c7cebbdabc8f7d5e79772/frontend/src/javascripts/
> receitas/main.js#L86
> [43]
>
> [4] https://github.com/okfn-brasil/gastos_abertos_website/blob/
> cd83cc446e6953b2281c7cebbdabc8f7d5e79772/frontend/src/javascripts/
> receitas/main.js#L199
> [44]
>
> []s
>
>
> Abs,
> E.
>
> On 02/03/2015 14:07, Luiz Armesto wrote:
>
>
> Links:
> ------
> [1] http://site.gastosabertos.org/receita
> [2] https://github.com/okfn-brasil/gastos_abertos/pull/134
> [3] https://github.com/okfn-brasil/gastos_abertos/issues/121
> [4] https://github.com/okfn-brasil/gastos_abertos/issues/132
> [5] mailto:Gastosabertos-dev em lists.okfn.org
> [6] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [7] mailto:Gastosabertos-dev em lists.okfn.org
> [8] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [9] mailto:Gastosabertos-dev em lists.okfn.org
> [10] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [11] mailto:Gastosabertos-dev em lists.okfn.org
> [12] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [13] mailto:Gastosabertos-dev em lists.okfn.org
> [14] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [15] mailto:Gastosabertos-dev em lists.okfn.org
> [16] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [17]
>
> http://demo.gastosabertos.org/receita/static/total_by_year_by_code/
> 2014.json
> [18] mailto:e em vaz.io
> [19]
>
> http://demo.gastosabertos.org/receita/static/total_by_year_by_code/
> 2014.json
> [20] http://demo.gastosabertos.org/api/v1/receita/totaldrilldown?
> year=2014
> [21] http://demo.gastosabertos.org/api/v1/receita/totaldrilldown?
> year=2014
> [22] mailto:Gastosabertos-dev em lists.okfn.org
> [23] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [24] mailto:Gastosabertos-dev em lists.okfn.org
> [25] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [26] mailto:Gastosabertos-dev em lists.okfn.org
> [27] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [28] mailto:Gastosabertos-dev em lists.okfn.org
> [29] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [30] https://github.com/okfn-brasil/gastos_abertos/pull/134
> [31] https://github.com/okfn-brasil/gastos_abertos/issues/121
> [32] mailto:Gastosabertos-dev em lists.okfn.org
> [33] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [34] mailto:Gastosabertos-dev em lists.okfn.org
> [35] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [36] mailto:e em vaz.io
> [37] mailto:Gastosabertos-dev em lists.okfn.org
> [38] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
> [39] mailto:e em vaz.io
> [40]
>
> https://github.com/okfn-brasil/gastos_abertos_website/blob/
> cd83cc446e6953b2281c7cebbdabc8f7d5e79772/frontend/src/javascripts/
> receitas/main.js#L188
> [41]
>
> https://github.com/okfn-brasil/gastos_abertos_website/blob/
> cd83cc446e6953b2281c7cebbdabc8f7d5e79772/frontend/src/javascripts/
> receitas/main.js#L71
> [42]
>
> https://github.com/okfn-brasil/gastos_abertos_website/blob/
> cd83cc446e6953b2281c7cebbdabc8f7d5e79772/frontend/src/javascripts/
> receitas/main.js#L211
> [43]
>
> https://github.com/okfn-brasil/gastos_abertos_website/blob/
> cd83cc446e6953b2281c7cebbdabc8f7d5e79772/frontend/src/javascripts/
> receitas/main.js#L86
> [44]
>
> https://github.com/okfn-brasil/gastos_abertos_website/blob/
> cd83cc446e6953b2281c7cebbdabc8f7d5e79772/frontend/src/javascripts/
> receitas/main.js#L199
>
>
> _______________________________________________
> Gastosabertos-dev mailing list
> Gastosabertos-dev em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
>
>
>
>
> --
> Luiz Armesto
>
>
>
>
> --
> Luiz Armesto
Mais detalhes sobre a lista de discussão Gastosabertos-dev