mirror of
https://0xacab.org/sutty/sutty
synced 2024-11-16 16:31:41 +00:00
3aa9af3fb5
tuvimos que volver a select2 4.0.5 porque hay un bug que impide procesar los data-*
211 lines
5.1 KiB
Markdown
211 lines
5.1 KiB
Markdown
# 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:
|
|
|
|
```yaml
|
|
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
|
|
```
|