أتفهم الرغبة في نقل المستخدمين إلى الوسيط include_condition في الاستخدام القياسي لطريقة add_to_serializer، أي لإضافة طرقهم الخاصة إلى serializers.
ومع ذلك، هناك بعض الحالات التي قد يرغب فيها المكون الإضافي في إضافة طريقة include_* إلى serializer لا تتطابق مع هذه الحالة، أي عندما لا تحدد ما إذا كانت السمة المخصصة الخاصة بك مدرجة، ولكنك تتجاوز طريقة include_* في serializer أساسي، على سبيل المثال:
أقدر أن هذا الاستخدام المحدد يمكن إعادة التفكير فيه لعدم الحاجة إلى تجاوز طريقة site serializer، أو يمكن تحقيق التجاوز بطرق أخرى، ولكني أتساءل عما إذا كان هناك أي عيب متأصل في السماح بهذا الاستخدام لطريقة add_to_serializer بهذه الطريقة، وما إذا كان الإهمال سيؤدي إلى إزالة استخدام الطريقة بهذه الطريقة.
لقد قدمنا مؤخرًا نظامًا جديدًا لـ ‘معدلات الإضافات’، وهي نقاط توسعة رخيصة جدًا تشبه DiscourseEvent ولكن تأخذ قيمة إدخال وتعيد قيمة. لذلك في حالتك، يمكنك تقديم طلب سحب أساسي لإضافة استدعاء DiscoursePluginRegistry.apply_modifier في طريقة include_ ذات الصلة، ثم يمكنك استخدام register_modifier في إضافتك لتجاوز القيمة.
من المحتمل أن نقوم بحظرها تمامًا في النهاية، نعم. بالإضافة إلى ذلك، أنت حقًا لا تريد استخدام طريقة تطبع ضوضاء الإهمال في السجلات.
إذا كان يجب عليك حقًا تجاوز طريقة دون تعاون من الأساس، فإن modify_class ستبدو الخيار الأفضل. السبب الرئيسي لوجود add_to_serializer مخصص هو أنه يحدد تلقائيًا طريقة include_* بحيث تنطبق فقط عند تمكين الإضافة.
هذا يعني أن مقتطف الشفرة الذي ربطته يحدد حاليًا طريقتين. include_wizard_required؟ و include_include_wizard_required؟
يقول ملف Readme هذا إنه “يعمل كمكدس (أول داخل، أول خارج)”، ولكن هذا طابور. المكدس هو أول داخل، آخر خارج. (لا يمكنني معرفة كيفية نسخ النص حتى على هاتفي).
هذه هي مشكلتي تقريبًا. لدي فجوة حديثة تقارب 10 سنوات حيث بالكاد اقتربت من جهاز كمبيوتر (بعد أكثر من 25 عامًا من العمل معهم) ويبدو الأمر وكأن هناك قسمًا كبيرًا مفقودًا من قاعدة المعرفة.
