[Gastosabertos-dev] ao

Quarta Março 4 16:43:11 UTC 2015

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
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/gastosabertos-dev/attachments/20150304/7b478f37/attachment-0003.html>