search

hacklabr / django-cards

Cards functionality for Django sites
GNU Affero General Public License v3.0
1 stars 3 forks source link

Cada eixo deve definir uma "imagem padrão" para seus cards sem imagem #8

Open laurybueno opened 7 years ago

laurybueno commented 7 years ago

Essa imagem será subida para a plataforma via Django Admin.

A API deve, no caso de um card não ter imagem alguma, retornar no JSON o endereço da imagem padrão do eixo correspondente.

tiagofassoni commented 7 years ago

Minha sugestão para isso: Criar um campo "imagem padrão" no eixo e mandar a URL dessa imagem de todo jeito.

Outra sugestão, que não sei se vale a pena fazer: colocar o campo "imagem padrão" no eixo e colocar toda a lógica no backend de cards para, se não tiver imagens, mandar uma "imagem" que é a imagem padrão do eixo.

leopiccionia commented 7 years ago

@tiagofassoni Se a serialização do eixo em /cards/api/cards retornar um campo de imagem, acho que ficará bom para mim e para você.

laurybueno commented 7 years ago

@leopiccionia esse método é ruim, pq retorna um monte de informações repetidas (cada card tem um eixo e cada eixo vai dar sua imagem padrão e isso vai se repetir pra todos os cards na lista). Se for pra fazer assim, melhor deixar o endpoint de cards como está e o front ler o endpoint de eixos, pegar as imagens de lá e ficar responsável por colocar a padrão qdo for o caso.

Mas a gente já bateu o martelo em deixar a complexidade da questão pro backend (mesmo pq o front do timtec vai ser refeito em algum momento). Valeus

leopiccionia commented 7 years ago

Nós já repetimos o ID e o nome do eixo para cada card da lista. Não entendi a diferença.

laurybueno commented 7 years ago

a diferença é piorar uma coisa ruim

laurybueno commented 7 years ago

por outro lado, trabalhando em cima da sua fala, @leopiccionia, uma alternativa é inverter de vez essa lógica: a listagem de cards só dar o id de eixo/público dela e caber ao front pegar infos detalhadas do back e mapeá-las para os cards adequados.

Não acho legal justamente por termos que refazer isso qdo mudarmos o front pro último angular, mas é uma opção sólida

leopiccionia commented 7 years ago

Não necessariamente é uma piora: é o clássico trade-off CPU-memória. No nosso caso em específico, ou aumentamos a memória ou aumentamos o tempo de processamento.

leopiccionia commented 7 years ago

Agora pensando, dá para fazer o programa economizar tanto espaço quanto tempo, utilizando programação dinâmica. Vai aumentar a inicialização do programa em alguns nanossegundos (ou seja, desprezível), e é um excelente compromisso.

laurybueno commented 7 years ago

Não sei se esta discussão está mesmo em cima do trade-off CPU/memória.

No meu entendimento, a questão maior é pensar quem vai gastar CPU e memória: cliente ou servidor.

Na minha proposta inicial, quem gasta mais é servidor. Na minha proposta alternativa, quem gasta é o cliente. Na sua, existe uma divisão dos trabalhos entre os dois, se eu entendi bem.

(explica o que vc pensou com programação dinâmica pra gente)

leopiccionia commented 7 years ago

Estou discutindo apenas em termos do cliente.

(Sejam n o número de cards e E o número de eixos.)

Temos que pensar que a operação de achar a imagem correspondente eixo do card é executada dentro de um loop de tamanho proporcional ao tamanho da lista de cards (portanto, O(n)). Dessa forma, se a busca pela imagem tomar tempo constante, o loop será O(n); se a busca for linear, ele será O(n × E). Eu não tenho conhecimento aprofundado do funcionamento do Angular, mas meu temor é esse loop rodar muitas vezes por segundo.

Buscar por um campo dentro de um objeto leva tempo constante (O(1)), mas o consumo de memória aumenta. Buscar o eixo corresponde numa array de eixos para, daí, buscar o campo dentro do objeto encontrado toma tempo O(E), mas há economia de memória.

A solução por programação dinâmica é construir um índice (pode ser um objeto ou array) em que a chave seja o ID do eixo e o valor seja o objeto que representa o eixo, retornado pela API /cards/api/axis -- você deve se lembrar de algo parecido das aulas de Desafios de Programação. Esse índice terá tamanho proporcional ao número de eixos (assumidamente menor que o número de cards) -- ou proporcional ao maior ID, no caso da array --, e o acesso a um eixo voltará a tomar O(1), portanto, será eficiente tanto em memória quando em processamento.

Obviamente, não precisamos nos preocupar com nada disso se a API /cards/api/cards retornar a imagem do card para o front-end.