Ayúdame a entender: el proceso posterior a la cocción

spirobel · 29 Mayo, 2020 09:51

Hola,
Me alegraría mucho si alguien pudiera ayudarme a entender cómo funciona el proceso de post-cocción. En particular, me interesa esta parte:

github.com/discourse/discourse

lib/cooked_post_processor.rb

956d15d13

# frozen_string_literal: true

# Post processing that we can do after a post has already been cooked.
# For example, inserting the onebox content, or image sizes/thumbnails.

class CookedPostProcessor
  LIGHTBOX_WRAPPER_CSS_CLASS = "lightbox-wrapper"
  LOADING_SIZE = 10
  LOADING_COLORS = 32

  attr_reader :cooking_options, :doc

  def initialize(post, opts = {})
    @dirty = false
    @opts = opts
    @post = post
    @previous_cooked = (@post.cooked || "").dup
    # NOTE: we re-cook the post here in order to prevent timing issues with edits
    # cf. https://meta.discourse.org/t/edit-of-rebaked-post-doesnt-show-in-html-only-in-raw/33815/6
    @cooking_options = post.cooking_options || opts[:cooking_options] || {}

This file has been truncated. show original

¿Por qué el procesamiento posterior ocurre después de que la publicación ya ha sido “cocinada”?

Quizás podríamos repasar el proceso de lo que se necesitaría hacer para añadir una función como oneboxes o “citas de usuarios específicos” si aún no existieran. Así que me topé con Prettytext discourse/app/assets/javascripts/pretty-text at f9608c0af5f7b1109117a5aba979acb00c28cf9a · discourse/discourse · GitHub
que maneja la conversión de y hacia Markdown y el renderizado de la caja de vista previa. También encontré la función rebake en el modelo de publicación en el backend:

github.com/discourse/discourse

app/models/post.rb

d9a02d133


      
                else
                  post.custom_fields["rebake_attempts"] = attempts + 1
                  post.save_custom_fields
                end
          
              end
            end
            problems
          end
          
          def rebake!(invalidate_broken_images: false, invalidate_oneboxes: false, priority: nil)
            new_cooked = cook(raw, topic_id: topic_id, invalidate_oneboxes: invalidate_oneboxes)
            old_cooked = cooked
          
            update_columns(
              cooked: new_cooked,
              baked_at: Time.zone.now,
              baked_version: BAKED_VERSION
            )
          
            if is_first_post?

que llama al método cook del PostAnalyzer:

github.com/discourse/discourse

app/models/post_analyzer.rb

9bff0882c


      
          end
          
          def has_oneboxes?
            return false unless @raw.present?
          
            cooked_stripped
            found_oneboxes?
          end
          
          # What we use to cook posts
          def cook(raw, opts = {})
            cook_method = opts[:cook_method]
            return raw if cook_method == Post.cook_methods[:raw_html]
          
            if cook_method == Post.cook_methods[:email]
              cooked = EmailCook.new(raw).cook(opts)
            else
              cooked = PrettyText.cook(raw, opts)
            end
          
            result = Oneboxer.apply(cooked) do |url|

esta función ejecuta la conversión de Markdown en JavaScript en el backend

github.com/discourse/discourse

lib/pretty_text.rb

9bff0882c


      
            @ctx
          end
          
          def self.reset_context
            @ctx_init.synchronize do
              @ctx&.dispose
              @ctx = nil
            end
          end
          
          def self.markdown(text, opts = {})
            # we use the exact same markdown converter as the client
            # TODO: use the same extensions on both client and server (in particular the template for mentions)
            baked = nil
            text = text || ""
          
            protect do
              context = v8
          
              custom_emoji = {}
              Emoji.custom.map { |e| custom_emoji[e.name] = e.url }

Mi idea era que se hace así para evitar duplicación de código, pero luego descubrí el

CookedPostProcessor

al que enlacé al principio. Parece que algunos procesos se realizan solo en JavaScript, mientras que otros se hacen tanto en JavaScript como en Ruby dentro del CookedPostProcessor. Para resumir: 1. Necesitas tener reglas de conversión de y hacia Markdown (parece que están solo en JavaScript) 2. Necesitas tener código para generar el HTML (algunas partes en JavaScript, pero otras también en Ruby). Me gustaría saber por qué el punto (2) se realiza parcialmente en JavaScript y parcialmente en Ruby. ¿Podrías darme un ejemplo? También me encantaría que corrigieras cualquier suposición errónea que haya hecho en este mensaje.
¡Muchísimas gracias!
Spirobel

fzngagan · 2 Julio, 2020 16:26

Para empezar, simplemente abre la pestaña Network de la consola de JavaScript para ver qué se captura en el frontend y se envía al servidor al crear una publicación. Esto significa que todos los datos enviados a la API de Rails son procesados posteriormente por Rails. Luego, en la tabla posts, verás las columnas raw y cooked, que indican las formas sin procesar y procesada de la publicación.

spirobel · 3 Julio, 2020 15:18

Vale, gracias por tu respuesta. Creo que simplemente exploraré esto pieza por pieza. Pienso que quizás este enfoque de “razonar a partir de primeros principios” que adopté no funciona porque esto surgió por razones históricas.

Tema		Respuestas	Vistas
Post Cooking Process with Landing Pages Development	0	369	5 Noviembre 2021
Importing posts with Markdown Migration	11	975	19 Octubre 2023
Edit of rebaked post doesn't show in HTML; only in raw Bug	8	1855	29 Septiembre 2015
How to decorate a post before it's cooked? Development	4	979	5 Marzo 2021
Working with different needs in raw/cooked content Development	7	5263	15 Mayo 2025

Ayúdame a entender: el proceso posterior a la cocción

Temas relacionados