Formulário customizado para adicionar múltiplos itens em um metadado Compound

Oi pessoal, tudo bem?
Cheguei com uma dúvida sobre a multiplicidade de dados em Metadados compostos.
Sei que por padrão o Compound não é para ser usado dessa forma mas foi a maneira mais simples que encontrei para replicar a estrutura de dados que precisamos.

Basicamente, estou usando um Compound, dentro de uma coleção intermediária Membros, que relaciona 1 item da coleção Companhia a N itens da coleção Pessoa, dentro de um intervalo de Data, onde para cada Pessoas eu teria 1 Função.

A estrutura da coleção Membros ficou a seguinte:

*Para resolver a questão de poder relacionar uma lista de termos em um campo composto, eu transformei Função, de taxonomia para uma coleção a parte, somente com os metadados simples (Titulo e Descrição)

Essa estrutura funciona bem e consegue cumprir o que foi proposto, porém a dúvida vem no contexto de cadastro Individual desse item no futuro, pois apesar de ter N Pessoas Relacionadas, o compound não permite que eu cadastre vários dados de uma vez, e no nosso cenário, após obter os dados da pesquisa sobre Membros de Companhia, eu vou ter uma lista de Pessoas e Funções, mas no cenário mais comum eu tenho N Pessoas com uma mesma Função, e para cadastrar isso o pesquisador precisaria inserir individualmente cada Pessoa e cada Função.

A dúvida é, existe alguma forma (algum hook ou alguma nova ideia), de cadastrar múltiplos dados no campo Compound, onde eu possa inserir várias Pessoas com a mesma Função, dar um “Inserir” e ele adicionar todos os dados de uma vez dentro do compound?

Porque eu sei que relacionar múltiplos dados no mesmo campo de relacionamento é inviável devido as estruturas do WP, por isso pensei em um formulário tipo Pop-Up via hook ou action, onde eu pudesse só selecionar os dados e o hook adicionaria programaticamente os dados via ID do metadado + ID do item.

Vou deixar o BO aqui, caso alguém queira se aventurar em pensar em algo do tipo ou tiver novas ideias.

Abraços

Oie @biancakaiserc, tudo bem?
Fiquei pensando em uma possibilidade de remodelar essa estrutura para evitar o uso do composto, principalmente se as funções exercidas pelas pessoas já estiverem previamente mapeadas.

Uma alternativa seria transformar as próprias Funções em metadados de relacionamento com a coleção Pessoas. Por exemplo:

  • Companhia (relacionamento)
  • Data inicial (data)
  • Data final (data)
  • Atores relacionados (relacionamento: múltiplo com coleção Pessoas)
  • Diretores relacionados (relacionamento: múltiplo com coleção Pessoas)
  • Produtores relacionados (relacionamento: múltiplo com coleção Pessoas)
  • Cenógrafos relacionados (relacionamento: múltiplo com coleção Pessoas)
  • etc.

Nesse modelo, a própria semântica do metadado já informa qual é a função exercida pela pessoa. Assim, se você tiver 20 pessoas exercendo a função de ator/atriz, poderia selecionar todas de uma vez no metadado “Atores relacionados”, aproveitando a possibilidade de múltiplos valores do metadado de relacionamento. A mesma pessoa também poderia aparecer em mais de um desses campos caso tenha exercido funções diferentes.

Acho que isso poderia simplificar bastante o cadastro, mas vejo duas questões importantes para saber se essa modelagem funcionaria bem no seu caso.

A primeira é a quantidade e a estabilidade das funções. Se vocês já têm um conjunto relativamente bem definido de funções, pode funcionar muito bem. Se forem muitas funções ou se novas surgirem com frequência, a estrutura pode acabar ficando rígida, porque cada nova função exigiria a criação de um novo metadado.

A segunda questão são as datas. Pelo modelo apresentado, fiquei com a dúvida se “Data inicial” e “Data final” se aplicam ao conjunto de membros da companhia ou à atuação de cada pessoa em determinada função. Se cada pessoa puder ter um período diferente de atuação, mesmo exercendo a mesma função, essa alternativa não resolveria completamente a necessidade de representar esses vínculos individualmente.

Então acho que ajudaria entender esses dois pontos: as funções já estão mapeadas e são relativamente estáveis? E o intervalo de datas é comum ao registro ou específico para cada relação Pessoa + Função?

Se essas características forem compartilhadas, talvez essa seja uma maneira mais simples de chegar ao resultado sem precisar do metadado composto.

Oi @Maria_Cecilia obrigada pela atenção,

Então, eu pensei nesse caso, mas acho que poderia ser inviável pois temos cerca de 34 funções hoje e esse número poderia aumentar no futuro, uma alternativa nesse contexto seria mapear as funções principais nesse formato, ai escolheríamos os campos que de fato tem mais de X cadastros com a mesma função, mas ai eu criaria uma duplicidade da informação que poderia me dar mais trabalho na hora de listar nos Itens Relacionados de Companhia :thinking:

Sobre a data, ela é abstraída do item composto pois essa coleção intermediária “Membros”, registra um “Elenco” em uma determinada “Temporada”, então não precisamos detalhar no micro quanto tempo determinada pessoa ficou naquele Elenco (Companhia + Data), apenas dizer quem estava naquele Elenco, naquela Temporada, e que função exerceu.

O caminho ideal na verdade seria, já colocar tudo isso em Companhia, mas para fazer isso eu teria que adicionar a Data no campo composto e ai eu criaria um sistema mais complexo de cadastro, porque precisaria cadastrar uma mesma Pessoa, com uma mesma Função em várias datas, ao separar a data eu evito o cenário de ter que registrar uma mesma pessoa múltiplas vezes no mesmo relacionamento, apesar de que isso ainda pode acontecer no cenário atual, mas seria uma repetição de Pessoa com uma nova função.

A estrutura que montei hoje está funcionando assim:

Ela seria uma representação dessa estrutura:

Eu estava pensando aqui na sua sugestão, e acho que ao invés de colocar múltiplos campos de relacionamento pessoa para cada função, eu vou criar um único campo relacionamento que aceita múltiplos só para algumas funções específicas que geralmente recebem mais dados como Ator/Cantor, e os demais eu deixo no composto, assim fica mais fácil gerenciar as variações das demais funções que podem mudar com o tempo