Boa tarde,
Dado um item mostrar a lista de itens, da mesma coleção ou não, que faz referência ao item atual através do uso de metadados do tipo relacionamento.
issues relacionadas:
Descrição:
Deve ser possível recuperar a lista de itens relacionados a um determinado item, essa lista deve ter seus itens agrupados pelo metadado de relacionamento utilizado para criar a relação, deve ser possível recuperar a informação do metadados e da coleção na qual o metadado de relacionamento pertence.
Deve ser possível especificar argumentos (WP_query?) adicionais para recuperar a lista de itens relacionados, por exemplo, a quantidade máxima de itens da lista, uma observação aqui que esses argumentos devem funcionar de forma genérica para todos os metadados de relacionados que podem estar presente no repositório.
Primeiros passos para o desenvolvimento:
- Adiciona um método na classe de repository do item para recuperar a lista de itens relacionados, essa função deve receber o item e a lista de argumentos.
- Adicionar um método na classe entity do item que deve trazer essa lista de itens relacionados (chamando o repository caso ainda não exista os dados)
- Adicionar uma função no theme_helper para trazer a lista de itens realacionadas ao item de forma a facilitar a construção dos themas
- Adicionar à resposta da API para o endpoint de items caso o paramento
related_itemsseja passado como um argumento do fetch_only.
@mateus.m.luna e @rodrigo que acham?
A discussão que vínhamos fazendo era sobre o quanto de informações este related_items vai trazer. Se ele vai trazer uma lista de IDs só, se tinha que ter pelo menos title e thumbnails, ou se viria ainda mais coisa. E também se haveria e como seria a paginação deste cara. Em resumo, a partir de quando seria necessário fazer uma requisição direta para a lista de itens para se ter informações completas.
Do ponto de vista da apresentação, estávamos pensando nesta função do template_helper ser uma chamada para um shortcode que renderizaria o mesmo componente Vue.js usado no bloco de Carrossel de Itens. Algo similar ao que fazermos com a lista de itens do bloco de busca facetada. A questão aqui é que podemos vir a querer outras visualizações que não só o carrossel. Além disso, o próprio carrossel tem uma limitação hoje de só renderizar itens dentro de uma coleção, e não permitir a nível repo… portanto seria mais uma coisa a se implementar.
Acho que aqui podemos trazer os itens igual a lista de itens do repositório, como devemos ter o par: metadado/coleção para agrupar os itens fica fácil montar uma URL de “ver mais”. Paginação penso que fica complicado por que seria um controle de paginação para cada grupo metadado/coleção.
Olá!
Estou criando em nível de repositório um metadado de relacionamento. Ocorre que ao preencher os campos o sistema coloca como obrigatoriedade selecionar uma coleção. Não tem jeito de deixar esse campo sem ser de preenchimento obrigatório? Pois, uma vez em nível de repositório, gostaria de relacionar itens independentemente das coleções que eles estão inseridos.
Desde já, agradeço.
PS: Não sei se estou comentando no tópico certo.
Oi @PriscillaTorres! De fato, nenhum dos dois é possível hoje, eu separaria em duas demandas neste caso (pegando aqui da outra questão que vc colocou lá no outro tópico também):
1 - Poder definir a ordem dos metadados nível repositório. Talvez isso seja algo que possamos oferecer depois de termos avançado com isso: Repository level settings page · Issue #438 · tainacan/tainacan · GitHub. Mas é complexo, porque tem questões como, por exemplo, se as coleções herdam os metadados nível repositório e mudam suas ordenações, como ficam os que foram definidas ordem ali e depois alterado lá?
2 - Permitir que metadados de relacionamento estejam vinculados a qualquer coleção. Este eu acho mais complexo porque tem configurações dos metadados nível repositório que estão muito “amarradas” aos metadados de cada coleção, como os metadados de busca. Mesmo sendo usado os nível repositório neste caso eu fico com um pouco de receio no impacto de performance que isto pode causar. De qualquer modo, vale a discussão, mas num tópico separado e realmente algo mais pro futuro…
1 curtida
Obrigada pela resposta 
A minha questão era que eu não tinha criado nenhum metadado de repositório. Eu criava os metadados em uma coleção e as outras herdavam dela com a ferramenta da coleção pai. Mas agora que fui criar os metadados de repositório e vi outras questões, que vou listar abaixo. Mas o principal é que os metadados de todos os itens de coleção ficaram duplicados e terei que preencher as informações novamente para cada item já enviado antes dessa atualização.
Outras falhas: Não dá pra criar metadados de título e descrição em nível de repositório, portanto em cada coleção o usuário precisa colocar as informações de descritores do que o metadado deve conter quando põe o mouse por sobre o ícone de “?” por exemplo - qualquer configuração nesse sentido deve ser feita uma a uma dentro de cada uma das coleções;
Não é possível exportar metadados de repositório, no caso de eu desejar fazer um BKP por exemplo (apesar de que não tentei exportá-los de uma coleção em branco, mesmo pq estou com problemas em fazer mapeamento de coleções e importar coleções mapeadas exportadas pelo próprio Tainacan);
Não consigo fazer mapeamento em nível de repositório (o mesmo tem acontecido com o mapeamento em nível de coleção);
E no caso dos itens relacionados, que é o assunto do tópico (rsrs, desculpe-me!), eu teria que criar um metadado de relacionamento novo para cada coleção, já que as coleções só se relacionam com a coleção escolhida nesse metadado. Não é o meu caso, mas pensando em um museu grande que tiver 100 coleções, terão que criar 100 metadados de relacionamento em nível de repositório para cada uma de suas coleções.
Eu não sei como eu consigo achar tantos bugs nas coisas, só acontece comigo rsrs
Entendo, e lamento pelo re-trabalho… levantamos essa discussão naquele tópico Hierarquia de Coleções justamente pra irmos vendo como isso afeta os usuários. O mais correto a meu ver continua sendo tratar as falhas do nível repositório e paralelamente pensar em uma solução para pessoas que como você usaram da hierarquia de coleção como “template” de metadados.
Sim, de fato não rola. Título e Descrição são metadados que todas as coleções tem desde o início, porém o caso mais comum é que em cada coleção eles possam vir a ter denominações diferentes, por isso deixamos eles ali. Porque se um item está em uma coleção e não em outra, ele essencialmente é “outra coisa”. Por exemplo, o título de uma coleção de Livros, é conceitualmente diferente de um título de uma coleção de Autores. A Descrição dos metadados tende a ser diferente também. Do ponto de vista do sistema, faz mais sentido implementarmos uma função que te ajude a criar novas coleções baseadas num “template” como mencionei acima, do que mudarmos este comportamento que está bem enraizado hoje.
Uai isso eu testei aqui e tá rolando… Fui em “Exportadores” → “Exportador CSV” → Escolhi uma coleção e no arquivo exportado vinham tanto os metadados da coleção quanto os que ela herdou. O que rola no seu? (favor abrir novo tópico se for um erro)
De fato não, porque como vão ser herdados por coleções diferentes, em cada coleção um metadado pode ter um significado diferente no mapeamento. O mapeamento de metadados é utilizado pelos expositores e exportadores, que hoje pelo menos só funcionam coleção por coleção.
Sim, como comentamos aqui, isso pode ser discutido e implementado, só fico com receio dos impactos de performance, porque busca em várias coleções juntas é uma coisa que pode se tornar pesado. 100 coleções em nenhum caso é OK Heheheh. Neste tipo de situação, precisamos começar a pensar na modelagem dos dados. Estes itens destas 100 coleções são estruturalmente diferentes do ponto de vista dos seus metadados? Ou será que não poderiam estar em algumas coleções juntas, porém separadas por taxonomias? E assim vai… Se quiser podemos discutir um pouco essas possibilidades de modelagem pro seu acervo (em outro tópico).
Sem problemas! Vai ficar tudo bem kkkkk. Só esperamos que entenda, tem coisas que não conseguimos alterar agora são características estruturantes do sistema e não necessariamente bugs. Mas outras coisas podem sim ser alteradas, só as ideias que precisam ser amadurecidas.
1 curtida
Olá! Aproveitando a discussão aqui sobre itens relacionados, estou com uma demanda neste sentido.
Estou desenvolvendo um portal da produção intelectual dos pesquisadores aqui do IGc/USP.
Então serão duas coleções no portal. Uma de AUTORES, e outra da PRODUÇÃO.
A coleção AUTORES tem o metadado que relaciona com a PRODUÇÃO, onde existem artigos, teses, eventos etc etc.
Enfim, na exibição de um item de AUTORES, na área dos itens relacionados, aparecerá sua produção.
A demanda aqui é: agrupar a exibição no tipo de produção, ou seja, artigos, teses etc, e dentro desse agrupamento, ordenar por ano.
Estão pensando em algo desse tipo?
Obrigado!
Oi @ezanon,
Então, acho que do lado do Admin isso é um pouco mais complicado, pq a ideia ali é realmente ficar só uma “prévia” dos itens, o restante ele veria em detalhes na lista filtrada pelo metadado.
Mas no lado público tem mais espaço pra isso. Hoje, esta lista de itens relacionados é criada usando o mesmo código que usamos para os blocos Gutenberg. Então na verdade, apesar de não existir na interface, dá pra configurar bem fácil pra ter a ordenação diferente por exemplo. Os filtros/agrupamentos por tipo aí já deve ser mais complicado.
De qualquer modo, se você tiver uma necessidade imediata disso, posso te indicar quais funções chamar no template (um tema filho ou plugin, por exemplo). Com alguns parâmetros dá pra conseguir o que vc quer. Se não for algo tão importante, eu aguardaria até termos recursos mais avançados para os blocos. Não só temos algumas issues que falam sobre ter filtros nos blocos (como essa) como pretendemos ter uma maneira de construir essa página toda do item via Gutenberg.
Enquanto não chegamos lá, vou me comprometer a tentar criar algumas opções extras pro tema do Tainacan Interface e pro plugin do Blocksy, que por enquanto são os caras que podem decidir algumas coisas sobre como estes itens relacionados são mostrados pro público.
Abraços!
Olá! @mateus.m.luna
Obrigado pela resposta. Eu agradeço se puder me enviar as dicas para eu tentar implementar de imediato.
Mas é muito bom saber dessas ideias para o futuro, especialmente montar o item via Gutemberg, acho que vai ser incrível.
Obrigado!