ساعدني في فهم: عملية ما بعد الطهي

مرحباً،
سأكون سعيداً جداً إذا أمكن لأحد مساعدتي في فهم كيفية عمل عملية ما بعد الطهي. أنا مهتم بشكل خاص بهذا الجزء:

لماذا تحدث معالجة ما بعد الطهي بعد أن يتم “طهي” المنشور بالفعل؟
ربما يمكننا استعراض العملية التي تتطلبها إضافة ميزة مثل “الصناديق المصغرة” (oneboxes) أو “اقتباسات مستخدمين محددين” لو لم تكن موجودة من الأساس. لقد صادفت مكتبة Prettytext:

التي تتولى تحويل النص من وإلى صيغة Markdown وعرض مربع المعاينة. كما وجدت دالة إعادة الخبز (rebake) في نموذج المنشور في الخلفية:

التي تستدعي دالة الطهي (cook method) في محلل المنشور (post_analyzer):

تقوم هذه الدالة بتشغيل تحويل Markdown باستخدام JavaScript في الخلفية:

كانت فكرتي أن هذا الترتيب يُتبع لتقليل تكرار الكود، لكنني اكتشفت بعد ذلك:

CookedPostProcessor

الذي ربطت به في الأعلى. يبدو أن بعض المعالجة تتم في JavaScript فقط، بينما يُنفذ بعضها الآخر في JavaScript وRuby معاً داخل CookedPostProcessor. لذا، للتلخيص: 1. يجب أن تتوفر قواعد التحويل من وإلى Markdown (يبدو أنها موجودة في JavaScript فقط). 2. يجب أن يتوفر كود لإنشاء HTML (بعضها في JavaScript وبعضها أيضاً في Ruby). أنا مهتم بمعرفة سبب تنفيذ النقطة (2) جزئياً في JavaScript وجزئياً في Ruby. ربما يمكنك إعطائي مثالاً توضيحياً. سأكون سعيداً جداً أيضاً إذا صححت أي افتراضات خاطئة وردت في هذا المنشور.
شكراً جزيلاً! :smiley:
Spirobel

للبدء، راجع تبويب الشبكة في وحدة تحكم JavaScript لمعرفة ما يتم التقاطه في الواجهة الأمامية وما يُمرّر إلى الخادم عند إنشاء منشور. وهذا يعني أن جميع البيانات المرسلة إلى واجهة برمجة التطبيقات الخاصة بـ Rails تُعالج لاحقًا بواسطة Rails. ثم في جدول posts، ستجد الأعمدة raw و cooked، والتي تُظهر الصيغة غير المعالجة والصيغة المعالجة للمنشور.

حسنًا، شكرًا لك على إجابتي. أعتقد أنني سأستكشف هذا الأمر جزءًا جزءًا. أظن أن نهج