Metadado que aceite HTML

Oi Pessoal, eu estou trabalhando no projeto Teatro Musicado SP que atualmente está em Vue.js e estou recriando o sistema usando Tainacan, porém esbarrei no problema de não aceitarmos HTML no campo de Textarea. Eu vi que temos uma issue no github aberta com o pedido de um editor de rich text para esse tipo de situação e queria entender se isso já caminhou de alguma forma, pois não podemos correr o risco de perder os hiperlinks de um dos metadados na migração do projeto. Será que alguem já conseguiu contornar essa situação de alguma forma ou tem alguma sugestão?

Eu não tive essa questão exatamente, mas estou com um projeto que deve precisar de um tipo de metadado novo. No caminho, vou considerar esse novo tipo WYSIWYG também, pois vejo ele sendo útil pro meu projeto :wink: Vou acompanhar esta e volto aqui caso essa parte vá pra frente.

Oi @biancakaiserc, seja bem vinda ao nosso fórum!

Sim, a issue Basic wysiwyg in text inputs · Issue #582 · tainacan/tainacan · GitHub é uma que eu venho querendo atacar faz um tempinho. Como mencionado lá, temos alguns desafios nessa área, em especial pensar o que fazer para as tags html não poluírem a busca textual e para evitar riscos de segurança. Vale mencionar que hoje no metadado de área de texto você pode ter sim algumas tags de formatação como <strong> (negrito), <em> (itálico) e listas <ul><li>.... Tags <a>, onde você poderia ter o rótulo e o link, entretanto são removidos por segurança. Mas se você colar lá um link válido em extenso (`https://tainacan.org`), ele vai sr convertido em link clicável na visualização.

Tem um debate mais filosófico disso tudo que é se os metadados não deveriam guardar mais “dados estruturados”, versus dado livre, mais solto. Sendo muito rígido se existem links eles poderiam estar em um metadado tipo URL (este sim permite links com rótulos, usando a notação [rótulo](link). Mas eu entendo que isso impacta na construção da página. Temos outra issue aberta que discute a possibilidade de se ter o Documento principal do item como uma página (uma criada via editor de blocos Gutenberg mesmo). Isso permitiria ter as informações mais soltas lá enquanto as estruturadas ficariam preservadas e buscáveis via metadado. Hoje isso já é possível com alguns filtros via código.

O meio termo é entregarmos aquela issue realmente limitada à formatação básica, entregando o que é possível hoje + algo básico como links. Talvez algo que aceite o que os editores Markdown aceitam, por exemplo.

Oi @mateus.m.luna , obrigada por responder minha dúvida.

Entendo a questão de segurança em não permitir todos os tipos de tag HTML, mas penso que os elementos de formatação de texto simples como títulos e links seriam fundamentais para garantir boa legibilidade de textos complexos no textarea, até por uma questão de semântica e acessibilidade, e se somente esses itens já fossem liberados já resolveria nosso problema.

Sobre o debate filosófico, eu também me questionei sobre isso, pensando em casos semelhantes ao nosso projeto, onde o acervo não é algo material e sim documental e relacionado puramente a dados históricos, para garantir a permanência da informação, no nosso caso da bibliografia desses artistas, como nesse exemplo da Lea Candini, eu vejo que esse texto precisaria ser diretamente relacionado ao item dessa coleção, mas a abordagem de estruturar uma página seria bem interessante, até para abrir possibilidades de outros projetos incluírem mais dados textuais e até estruturados como tabelas sobre um determinado item.

Já temos alguma POC ou documentação sobre essa possibilidade de usar páginas como documento do item?

Se tiver outra abordagem para nos ajudar com o nosso problema também fique a vontade.

Oi @mateus.m.luna tudo bem?

Conversei com a coordenadora do projeto e realmente, se tivermos um editor simples que aceite os hiperlinks, já resolveria nosso problema.

Existe alguma previsibilidade de quando teríamos isso disponível no sistema?
Tem alguma forma de fazermos isso temporariamente no nosso projeto até ter uma nova atualização com essa feature?

Obrigada

Oi @biancakaiserc!

Andei revisando aqui essa questão. De fato retiramos a permissão de ter links montados na mão lá por uma questão de segurança. Olhei até no histórico dos commits e achei onde isso acontecia:

Eu estou considerando criar um filtro ali pra que vai código as pessoas possam desabilitar isso, pelo menos até que tenhamos um metadado dedicado para formatações mais complexas.

Eu estou trabalhando justo nisso num plugin para testes :wink:

Está quase pronto. Faltam alguns detalhes pra liberar pra outras pessoas testarem. Em breve devo voltar aqui com novidades :smiley:

@biancakaiserc , consegui fazer funcionar como eu gostaria esse campo HTML como um novo tipo de metadado.

Contudo é um caso a ser discutido mais profundamente. Quero entender melhor as razões pelas quais o link foi removido originalmente e se ainda é necessário ter essa restrição. Além disso, eu só me preocupei em editar/salvar o metadado. Importação, REST, etc. não foi testado nem avaliado se poderia trazer algum problema de segurança também.

Como palhinha, aqui está a interface de edição do item :slight_smile:

Quando estiver discutida a questão de segurança que originou a remoção original dos links de dentro dos campos do Tainacan, volto aqui.

@biancakaiserc se você puder nos dê uma semana pra eu e o @marvila discutirmos as soluções, ok? De algum jeito vai sair heheh