تواصل معي عميل بطلب إنشاء دليل مستخدم يعتمد على البطاقات.
بما أنه مستضاف على discourse.org، فقد قلت في البداية إن هذا غير ممكن (باستثناء أي مشكلات تتعلق بالأداء)، حيث أن السمات المطلوبة لملء بطاقة المستخدم غير متاحة في كائن المستخدم المُسلسل مع عناصر الدليل.
ومع ذلك، وبعد مناقشة الأمر بشكل أعمق، استنتجت أن أحد الأساليب الممكنة هو تقديم طلب دمج (PR) في النواة (core) لإضافة سمات المستخدم إلى مُسلسل عناصر الدليل عبر إعداد موقع. الفكرة هي أن هذه الوظيفة ستكون مفيدة لأنماط مختلفة من أدلة المستخدمين التي تتطلب مزيجًا متنوعًا من سمات المستخدم (مثال أدناه).
عند تجربتي لهذا الأسلوب، توصلت إلى نهج بسيط نسبيًا، يمكنك مشاهدته في هذا الاختلاف (diff):
إنشاء مُسلسل مخصص يُسمى DirectoryItemUserSerializer (لقد بدا لي دائمًا أن “UserSerializer” الحالي داخل DirectoryItemSerializer غريب بعض الشيء).
إذا قام مسؤول الموقع باختيار أي سمات مستخدم لإضافتها:
إنشاء مستخدم مُسلسل للاستفادة من الحماية التي يوفرها ذلك المُسلسل، مثل سمات الموظفين / الخاصة / غير الموثوقة.
تسلسل أي سمات مضافة تمر عبر فلتر UserSerializer.
تتمثل الأهداف هنا في:
عدم التأثير على السلوك الحالي بأي شكل من الأشكال.
تسلسل السمات المطلوبة فقط.
إذا كنتم موافقين على هذا النهج/الطلب، فسأنهي العمل بإجراء ما يلي:
إضافة تحقق (validation) على إعداد الموقع (أي للتأكد من أن السلسلة المدخلة هي سمة مستخدم).
إضافة اختبارات.
غير أنني اعتبرت أنه من الأفضل عرض هذا الأمر عليكم أولاً.
مثال
كمثال على نوع الوظيفة التي سيُتيحها هذا، تظهر الصورة التالية من بيئتي المحلية بعد استخدام هذا التغيير في النواة فقط + مكون سمة (theme component) يُغلف الدليل الحالي ويستخدم مكون بطاقة مستخدم معدل:
أعتقد أن @blake و @awesomerobot يعملان مع عميل آخر لديه متطلبات مماثلة. أنا منفتح نوعًا ما على فكرة وجود إعداد موقع مشابه لما لدينا في always_include_topic_excerpts.
لكنني أود أن يتم اختبار هذا الإعداد، وأود أيضًا أن يكون إعداد الموقع مخفيًا.
أعلم أن @david مهتم أيضًا بهذه المشكلة، وأنا متردد قليلاً في هذا الشأن، لكن ربما يكون الحل الأبعد مدى والأكثر نظافة هو:
إضافة إعدادات موقع مخفية لـ “السماح للإضافات (plugins) والقوالب (themes) باختيار الحصول على معلومات إضافية مُسلسلة”، مع افتراض إيقافها افتراضيًا.
ثم وجود بروتوكول في القوالب والإضافات لـ “طلب” هذه المعلومات الإضافية.
الميزة هنا هي أن بعض القوالب سيكون لديها المعلومات الإضافية المُسلسلة بينما لن يكون لدى البعض الآخر.
أود الانتظار قليلاً مع David قبل منحك الضوء الأخضر.
ماذا عن جعل مُسلسل دليل المستخدمين يقبل معلمة جديدة مثل users.json?include_profile=true؟
ثم يمكننا إضافة واجهة برمجة تطبيقات (API) لإضافات الجافا سكريبت تسمح للقوالب بإضافة هذه المعلمة:
api.userListIncludeProfile(true)
سيشمل “الملف الشخصي” كل العناصر الموجودة في مُسلسل المستخدم العادي (مع الحرص على عدم إدخال استعلامات N+1). لا أعتقد أن تحديد الحقول الفردية سيحدث فرقًا كبيرًا في الأداء، لذا في رأيي يجب أن نُبسّط الأمر.
يمكن أن تعمل نفس الطريقة أيضًا مع قوائم المواضيع باستخدام ?include_excerpts=true.
كما أنني أحب هذا الحل لأنه يعني أن “إعدادات المُسلسل لكل قالب” لن تتأثر بذاكرة التخزين المؤقت للتحليل المجهول!
قريب لكن هذا لا يعمل بسلاسة لأنه عندما تنتقل إلى الصفحة الرئيسية للموقع أو إلى مسار u، لا تتوفر لك رفاهية إضافة معلمة إلى المسار، نحتاج إلى تغيير القيم الافتراضية
في هذه الحالة، أعتقد أن إعداد موقع مخفي هو نقطة انطلاق جيدة. سيكون من الجميل جعله خاصًا بكل سمة، لكننا بحاجة إلى بناء بعض البنية التحتية هناك أولاً. ما زلت أعتقد أن إعداد “قائمة المستخدمين تتضمن الملف الشخصي” من نوع boolean سيكون أسهل في الفهم.
أمر واحد يحتاج إلى توضيح هنا وهو البروتوكول المطلوب للحصول على بيانات إضافية. هل يمكننا الاعتماد على إعداد الموقع في الواجهة الأمامية لطلب البيانات، أم كما اقترحت، إضافة واجهة برمجة تطبيقات أخرى في plugin-api؟
