sutty/doc/plantillas.md

Plantillas de artículos

Las plantillas de artículos son archivos YML con la estructura de campos a utilizar en la creación de un artículo. Dependiendo del tipo de artículo que elijamos, el editor del artículo cargará los campos necesarios.

Las plantillas residen en la colección _templates como archivos markdown. Esto permite que Jekyll los cargue como una colección a través de esa feature ya implementada, reciclando código.

Además, permite que las plantillas tengan, además de una estructura de datos YAML por defecto, un cuerpo por defecto, si quisiéramos tener una estructura del documento también.

Estructura del documento

---
title: ""
categories: []
tags: []
related_articles: []
destacado: false
resumen: ""
descripcion_detallada: ""
---

# Título de primer nivel

Un resumen que quieras poner aquí.  Esto irá en el editor de texto.

Entonces, en un primer momento, el formulario se arma en base a los tipos de datos que se espera en un campo. Si el valor es "", se espera un campo de texto, si es [], se espera un array y así.

Pero:

• Cómo distinguir entre un campo de texto largo y uno más corto?

• El campo related_articles debería ser autocompletado a partir de los títulos de otros artículos cargados, entonces cómo indicar esto?

La conversión de cyber-women.com debería ser así:

---
categories: []
cover: ""
lang:
  es: ""
  en: ""
  ar: ""
layout: ""
title: ""
objetivos: ""
tags: []
permalink: ""
dir: ""
---

Pero acá no se puede distinguir que en realidad en cover y en permalink van paths, que los idiomas se autocompletan con titulos de otra colección, que tags y categories se autocompletan con valores que hay en otros artículos y que dir es uno de ltr o rtl.

dir es fácil, se pone un array con los valores que van:

---
categories: []
cover: ""
lang:
  es: ""
  en: ""
  ar: ""
layout: ""
title: ""
objetivos: ""
tags: []
permalink: ""
dir: [ ltr, rtl ]
---

La otra opción es hacer una lista de las propiedades que se autocompletan, por ejemplo, los campos estándar:

• categories
• tags
• cover
• layout
• dir

Ya tienen programáticamente sus valores. Pero sería laburo doble porque el editor de plantillas tiene que poder crear campos arbitrarios con valores predeterminados.

Aunque el editor de plantillas todavía no lo necesitamos hacer?

---
categories: [site/categories]
cover: string
lang:
  es: en/title:en/slug
  en: es/title:es/slug
  ar: ar/title:ar/slug
layout: site/layouts
title: string
objetivos: text
tags: [site/tags]
permalink: string
dir: [ ltr, rtl ]
---

Donde site/categories equivale a @site.everything_of('categories') y en/slug a @site.everything_of('slug', lang: 'en').

Al separar con :, estamos diciendo qué valores mostrar y a cuáles mapearlos, entonces en/slug:en/title muestra un selector de todos los títulos, pero almacena el slug correspondiente.

Para saber si un valor es un array, encontramos un array y miramos dentro qué tipos de valores vamos a rellenar.

luego, el editor de plantillas de posts permite crear estos tipos de campos con un formulario dinamico

Las plantillas tienen un layout correspondiente. Luego se puede sugerir y que las usuarias lo cambian.

No es necesario definir los campos estandar categories, lang, layout, title, tags, slug, permalink y dir.

Finalmente, solo es necesario definir los campos extra:

---
cover: string
objetivos: text
habilidades: 'posts/habilidades'
conocimientos: ['posts/conocimientos']
sesiones_ejercicios_relacionados: ['posts/slug:posts/title']
destacado: false
---

Donde string y text indican valores de texto de distintos largos (text y textarea en el formulario), false un valor binario (un checkbox) y coleccion/valor y coleccion/valor:coleccion/valor_a_mostrar en valores tomados de otras colecciones. Cuando están entre [], permite múltiples valores.

Entonces, para resumir:

• La plantilla se coloca en _templates/nombre_de_la_plantilla.markdown
• Es un documento Jekyll con frontmatter y contenido
• El frontmatter trae los campos extra a completar desde la carga de artículos
• El slug de la plantilla se convierte en el layout sugerido del post, es decir que debería existir un _layouts/nombre_de_la_plantilla.html correspondiente.
• El _config.yml del sitio debe contener:

collections:
  - templates

Para poder cargar la colección de plantillas.

TODO: agregarlo especificamente en app/models/site.rb al cargar el sitio.

Plantillas complejas

Algunas plantillas necesitan comportamientos más complejos, por ejemplo cuando un campo es requerido o no es público.

campo:
  help: "Un texto de ayuda"
  public: false
  required: true
  value: {bool,string,text,array,url,email}
  min: 0
  max: 100
  multiple: false

Ahora los value pueden estar anidados, es decir que dentro de cada value puede haber una serie de campo con los mismos valores.

Las plantillas más simples asumen ciertos valores por defecto:

help: nil
public: true
required: false
min: nil
max: nil
multiple: true
open: true