Possibilitar alterar as configurações através de páginas HTML

[edusantana]

Comportamento esperado:

O ideal seria possibilitar realizar as configurações através de HTML que permite a construção de formulários que possibilitam uma experiência de interações melhores.

Atualmente é possível ler as configurações apenas de YAML ou PDF.

[edusantana]

@cauachagas enviou a seguinte imagem sobre essa idéia:

[cauachagas]

Este primeiro arquivo compactado contém só o formulário html

configuracao.html.zip

O segundo, contém o formulário e a pasta arquivos necessários. Quando o formulário html é salvo (Ctrl + S), cria uma pasta com esses arquivos (são as figuras contidas em "imagens/configuracao/"). Deve haver um jeito de colocar "imagens/configuracao" como diretório de imagens, pra evitar esse comportamento. Infelizmente, não tenho conhecimento em html.

configuracao-html.zip

Todos os campos, coloquei com

<form></form>

, porém só as estruturas

<select></select>

, que geram lista com opções (como tipo de trabalho e adicionar/desativar anexos), conseguem ser extraídos com o pacote nokogiri do ruby. Abaixo um exemplo de como podem ser extraídos as informações com doc.search('form')[n].text, onde n significa a ordem apresentada das informações pedidas no arquivo configuracao.pdf

require 'nokogiri'

doc = Nokogiri::HTML(open('configuracao.html'), nil, "UTF-8")

nivel_educacao = doc.search('form')[0].text # form. lista

projeto_combo = doc.search('form')[1].text # form. lista

instituicao = doc.search('form')[2].text # form. area de texto; não consegue ser extraído

[edusantana]

Se eu fosse fazer isso daí, provavelmente eu iria fazer uma aplicação sinatra.

Como você faz para persistir os dados do formulário?

[edusantana]

@cauachagas Entendi o funcionamento proposto, é similar ao PDF. Persistir os dados dentro do arquivo HTML e salvar como outro arquivo HTML.

Nessa sua abordagem iria ler os dados HTML e exportaria para o formato YAML, que é lido pelo limarka.

---

Eu realmente estava pensando em uma aplicação web que edita os parâmetros, com múltiplas páginas, uma para cada seção. Com recursos para validar os dados inseridos etc.

Eu pensei no sinatra porque ele possibilita tudo isso e não é um monstro como rails.

Independente do que desejar fazer, recomendo a criação de um projeto separado, criado em https://github.com/limarka

Da mesma forma que do pandoc_abnt, que é utilizado pelo limarka.

Se precisar de ajuda estou a disposição.

[cauachagas]

Não tenho conhecimento de html. Apenas usei o Google. Crei esse formulário usando pandoc. Basicamente odt --> md --> html. Só fiz editar o arquivo html gerado com atributos do tipo formulário.

Em 154, fala sobre alternativas ao LaTeX (html para pdf, no caso). Então, pensei em criar um formulário html, caso o limarka comece a usar html.

Lendo um pouco sobre extrair informações de formulários html, vi sobre incorporar o Ruby (um tal de erb) ou até usar outra linguagem, como o python, pra mexer em HTML. Enfim... Vou tentar explorar sobre o assunto por esses dias.

[edusantana]

Em #154, fala sobre alternativas ao LaTeX (html para pdf, no caso). Então, pensei em criar um formulário html, caso o limarka comece a usar html.

Isso é outra coisa. Atualmente podemos realizar as configurações através de código YAML ou PDF, e talvez em HTML no futuro.

Independente da forma como as configurações são lidas, os passos como o limarka processa as informações necessita do LaTeX e do abntex2 (quem possibilita a compatibilidade com o ABNT).

Torna-se independente do LaTeX significa implementar tudo o que o abntex2 (verificar compatibilidade com as normas da ABNT) através de estilos CSS para impressão.

Da última vez que investiguei isso não era possível ainda. Basicamente é o seguinte:

As vezes na internet quando clicamos para imprimir uma página a impressão remove alguns elementos da página desnecessários, e torna o documento impresso melhor.
Implementar #154 significa criar a possibilidade de imprimir uma página HTML de acordo com as normas da ABNT: cabeçalhos, numeração de página, numeração de capítulos e seções, espaçamentos, tamanho de fontes, etc.

[sergiopvilar]

Porque não usar o HTML pra gerar um código YAML que pode ser criado pelo próprio usuário?

Por ex, o usuário usa o HTML pra fazer todas configurações e ao final tem um YAML pronto.

[cauachagas]

@sergiopvilar , tens experiência nesse tópico? Eu criei o repositório limarka-sinatra com esse objetivo, mas não tenho muita afinidade com o assunto. Até onde lembro, estava funcional. PRs serão apreciados.

A dificuldade que tive foi em recuperar os valores de listas (drop-down) a partir de um .yaml. Por exemplo, em Nível de Educação do Trabalho, eu seleciono "Mestrado". Ao submeter o formulário, criará um .yaml válido para o Limarka. Supondo que foi finalizado http://localhost:4567, caso o usuário queira trocar alguma informação, ao abrir o formulário novamente, em Nível de Educação do Trabalho estará o valor padrão, que é "Graduação" e não "Mestrado", como havia primeiramente submetido.

Isso causa um efeito dominó, pois há outras informações que são em drop-down. Por esse motivo, não criei um formulário completo.

[sergiopvilar]

@cauachagas tenho experiência sim! Estou em semana de provas e posso contribuir com isso a partir do dia 19, vou ver como está o estado atual e o que pode ser feito.

[sergiopvilar]

@cauachagas acabei arrumando um tempo e criei o MR (limarka/limarka-sinatra#7), só fiquei na dúvida dos valores possíveis pra a chave tipo.

[cauachagas]

@sergiopvilar , obrigado. Quanto aos valores. Acho que não existe a chave tipo e sim tipo_do_trabalho. Não sei como não havia notado.

Quantos aos valores dessa variável, estão aqui

Retirado da versão mais recente do limarka, tem esse arquivo .yaml do formulário completo:

---
instituicao: Universidade/Faculdade do Brasil
author: Nome do autor
title: Título do trabalho
local: Cidade - UF
date: '2019'
capa_pdf_caminho: ''
titulacao: Minha-titulação
curso: Meu-curso
programa: Programa de Pós-Graduação em XXX
area_de_concentracao: Computação
linha_de_pesquisa: ''
coorientador: ''
orientador: Nome-do-Orientador
referencias_caminho: referencias.bib
proposito: ''
resumo: ''
palavras_chave: ''
keywords: ''
abstract_texto: ''
resumen: ''
palabras_clave: ''
resume: ''
mots_cles: ''
siglas:
- s: ABNT
  d: Associação Brasileira de Normas Técnicas
simbolos: 
dedicatoria: ''
agradecimentos: ''
epigrafe: ''
avaliador2: Nome-do-Prof-Convidado2
aprovacao_dia: '1'
avaliador1: Nome-do-Prof-Convidado1
avaliador3: ''
graduacao: true
especializacao: false
mestrado: false
doutorado: false
tipo_do_trabalho: Monografia
incluir_ficha_catalografica: false
folha_de_aprovacao: false
projeto: true
apendices: false
anexos: false
errata: false
referencias_sistema: alf
lista_ilustracoes: false
lista_quadros: yes
lista_tabelas: yes
---

[edusantana]

@sergiopvilar para desenvolver uma solução html eu escolheria uma das seguintes alternativas:

1. aplicação nodejs/express/react
2. aplicação python/flask
3. aplicação ruby/sinatra

As alternativas estão listadas na ordem que acho mais relevante:

1. Pró: Seria possível compilar código executável para cada plataforma. Fica solução portável. Contra: solução mais técnica/complexa para desenvolver. Desenvolvedores precisam conhecer estas tecnologias para poder contribuir.
2. Pró: Os linux já vem com python, seria menos dependência que precisariam instalar. O flask é simples, e aprender python sempre é legal. Contra: usuário precisaria instalar python no windows.
3. Pró: feito na mesma linguagem do limarka, fica fácil compreender a linguagem e código dos dois projetos. Escrever códigos em Ruby fácil e chega a ser prazeroso. Contra: usuário precisa instalar ruby, no entanto, atualmente já fazem isso para usar o limarka.

Acho que daria para ser aproveitado como um projeto em alguma disciplina de graduação em computação. :)

[edusantana]

Eu também viria a possibilidade de fazer uma aplicação desktop electron para edição.

[sergiopvilar]

@edusantana eu gosto muito da ideia do app com electron pois podemos distribuir um portável .exe, .app, etc dentro do repositório do trabalho-academico entretanto pode ser que haja mais uma opção pra isso.

Eu tive uma idéia durante esse fim de semana e gostaria de compartilhar: e se a gente não precisar de nenhum back-end pra rodar isso? Eu pensei em:

• Distribuirmos um HTML contido no repositório do trabalho-academico
• No HTML, assim como no limarka-sinatra, é possível configurar todo o projeto
• Os dados são persistidos e carregados do localStorage
• Ao fim da configuração o usuário pode fazer download do configuracao.yaml

A idéia é que o usuário possa abrir o HTML, atualizar as configurações, baixar o .yaml e salvar na pasta do projeto. O pró é que não necessita nenhuma complexidade adicional na configuração de ambiente, nada precisa ser instalado. O contra é que a etapa de salvar o arquivo .yaml na pasta é necessária, mas comparado ao setup de um ambiente node/python/ruby, eu acho bem mais simples.

Pra projetos já existentes, podemos colocar uma opção de importar um configuracao.yaml já existente e carregar os dados dele no formulário da página HTML.

[edusantana]

Legal, parece simples.

Eu já fiz uma extensão para o chrome que utiliza storage. O legal de distribuir através de uma extensão é que os usuários tem atualização automática. Talvez precise trabalho extra para questões de portabilidade (Edge e Firefox), mas pelo menos funciona no window e linux.

Se fizer através de uma extensão chrome, posso até contribuir também.