مرحباً
لقد بدأت مؤخرًا العمل مع Discourse ومن خلال تجربتي التي استمرت أسبوعًا واحدًا، يمكنني بالتأكيد القول أن مستوى الدخول مرتفع جدًا للمطور الذي يحتاج فعليًا إلى تعديل الأشياء الأساسية، ويرجع ذلك إلى نقص الوثائق/المعلومات الحقيقية، خاصة إذا كنا نتحدث عن الخيارات الجديدة الأحدث، حيث لا يمكنني العثور إلا على شيء لا يعمل بعد الآن للإصدار 3.6.0 بدلاً من النهج الجديد وحتى لو وجدت بعضها، فإن مستوى التفاصيل فيها منخفض، ولا توجد أمثلة واقعية أو شروحات أكثر تفصيلاً حول كيفية استخدام الأشياء.
ومع ذلك، أحتاج إلى تعديل المكون second-factor-add-totp.gjs ولم أتمكن من القيام بذلك لعدم وجود معلومات حول كيفية القيام بذلك بشكل صحيح في نسقي المخصص.
وجدت أن هناك شيئًا يسمى PluginOutlet مصممًا للعمل كخطاف يمكنك استخدامه لحقن التعليمات البرمجية المخصصة الخاصة بك أو حتى تعديل المخرجات إذا كان العنصر مغلفًا في PluginOutlet (لست متأكدًا، هناك شيء مثل api.renderInOutlet، لكنني لم أجد أي معلومات طبيعية حول كيفية استخدامه). بالنظر إلى مكونات Ember هذه، لا أرى PluginOutlet الذي يمكن أن يساعد على الأقل في إجراء بعض التعديلات على الهيكل باستخدام JavaScript نقي على الأقل.
هل يمكنك توضيح ما إذا كان يمكن إضافة شيء هناك وما إذا كان بإمكاني استخدامه لتعديل هيكل النافذة المنبثقة أو على الأقل استخدام JavaScript نقي لنقل بعض العناصر إلى أماكنها.
أيضًا ربما لم أجد، ولكن هل هناك وثائق مع أمثلة للنهج الجديدة؟
بالتأكيد.
إذن، وفقًا للإصدار “المعدل” الذي لدي، أحتاج إلى تحديث التصميم قليلاً لـ MFA Modal (عندما يجب على المستخدم إعداد تطبيق مصادقة لـ MFA).
بالتحديث، أعني على سبيل المثال نقل رمز QR في بنية HTML، لكي أكون أكثر تحديدًا، نص موقع “js.user.second_factor.enable_description”، يجب أن يكون رمز QR في مكان ما بين النص الجديد المقدم (علامات HTML).
مثال آخر هو التأكد من أن “أدخل يدويًا” بدلاً من ذلك يعرض الرمز الفعلي الذي يمكن نسخه عند النقر عليه (يدويًا عبر مشغل JS للنقر حتى يظهر وتحريكه فقط).
يمكن تحقيق كل هذا باستخدام معالجات JS العادية، دون إعادة بناء هيكلية للمكون الأصلي، ولكن التحدي الرئيسي بالنسبة لي هو تحديد مكان يمكن وضع هذا JS فيه بحيث يتم تشغيله عند فتح النافذة المنبثقة، وهو ما لم أتمكن من تحديده بعد.
توضيح إضافي: أنا أستخدم سمة مخصصة مخزنة باستخدام خيار GIT.
مرحباً @Yan_Rudenko، أفضل المستندات للبدء بها هي على الأرجح هذا البرنامج التعليمي:
كما ذكرت، فإن منافذ الإضافات (Plugin Outlets) هي أفضل طريقة لتخصيص واجهة المستخدم. لكن هذه ليست متاحة في كل مكان. أجزاء معينة فقط من واجهة المستخدم مصممة ليتم تخصيصها.
ستؤدي معالجة DOM باستخدام JS العادية إلى حدوث أخطاء، لأن إطار العرض الخاص بنا سيفقد السيطرة على العناصر التي تم عرضها على الشاشة. من الأفضل الالتزام بمنافذ الإضافات المدعومة وواجهات برمجة تطبيقات JS الأخرى الخاصة بـ Discourse (والتي تتم تغطيتها أيضًا في البرنامج التعليمي).
مرحباً @david، شكراً لك على رابط البرنامج التعليمي، ولكني تفقدته بالفعل ولم أجد أي إجابات كنت أبحث عنها، الأمثلة بحد ذاتها أساسية ولا تغطي على سبيل المثال كيفية الحصول على فئة معينة (بدلاً من إجراء استدعاء Ajax) أو كيفية استخدام واجهة برمجة تطبيقات Discourse في الكود بالكامل (تم ذكر https://docs.discourse.org/)، وهو موجود حسب ما أعرف وأرى، لهذا السبب كتبت هنا للحصول على مزيد من التفاصيل من الأشخاص الذين يتعاملون مع Discourse بشكل يومي ويعرفون الكثير من الأشياء غير الموجودة في التوثيق.
أتفهم تمامًا أن استخدام JavaScript النقي قد يسبب مشاكل، ولكنه الشيء الوحيد الذي توصلت إليه حتى الآن، ربما في المستقبل سأتمكن من تعديل بعض الأشياء بطريقة أكثر ملاءمة إذا وجدت مثل هذه.
لذا، إذا فهمت هذا بشكل صحيح، في الإصدار الحالي من Discourse الذي أستخدمه، وهو 3.6.0.beta2-latest، فإن التغييرات التي ذكرتها لن تكون قابلة للتنفيذ باستخدام الأدوات المدمجة في Discourse؟ بسبب نقص PluginOutlets في هذه المكونات؟
هل يفكر فريق التطوير في إضافة هذه المكونات في الإصدارات المستقبلية، حيث أفترض أنه لا توجد مشاكل فنية مع ذلك، بل هو مسألة قرار من بعض الأشخاص الذين يعملون على هذا؟
@david، شكراً لك على الاقتراح، سأأخذه في الاعتبار عندما يكون لدي وقت فعلي للقيام بذلك، ولكن عليك أن تفهم أنه بالنسبة لشخص دخل للتو إلى Discourse، قد يستغرق هذا بعض الوقت، حيث أحتاج إلى فرز كيفية إعداد واحد مع التغييرات الصحيحة + كما ذكرت مرحلة الموافقة + الوقت قبل أن يدخل في الإصدار التالي نفسه.
كنت آمل أن يقوم فريق التطوير، الأكثر تأهيلاً، بإعداده في ساعة واحدة إذا كان الأمر يتعلق فقط بإضافة غلاف PluginOutlet وعدد قليل داخل المكونات في أماكن مختلفة (قد أكون مخطئًا)، مما سيقلل من الوقت الذي يستغرقه تسليم هذا في الإصدار الجديد.
ومع ذلك، كما ذكرت أعلاه، سآخذ اقتراحك في الاعتبار.
لا أزال لم أتلق ردًا بخصوص سؤالي، إذا كان من الممكن القيام بالأشياء التي ذكرتها ضمن الإصدار الحالي من Discourse أو يجب إضافة/المساهمة في التغييرات التي ذكرتها أولاً (إضافة PluginOutlet في تلك المكونات)؟
السبب في أنني أسأل هذا هو أن لدي نطاق عمل مطلوب إنجازه، ولكني لا أستطيع القيام به وأحتاج إلى تقديم شرح لسبب عدم قدرتي على القيام به للفريق، لذلك إما أن يتغير نطاق العمل للقيام بالأشياء التي يمكننا القيام بها أو سأضطر إلى المساهمة في هذا على أمل أن يتم إضافته إلى النواة وإصداره في الإصدار القادم. لذا أحتاج إلى تأكيد من فريق تطوير Discourse ما إذا كان هذا ممكنًا أم لا.
بالنظر أيضًا إلى المستودع الرئيسي https://github.com/discourse/discourse، لا أرى قسم المشكلات بجوار طلبات السحب، حيث يقوم الأشخاص عادةً بإنشاء مشكلات تصف ما إذا كان هناك شيء مكسور أو مفقود.
الأشياء المكسورة تذهب إلى #bug، والميزات المفقودة تذهب إلى Feature (أو في حالة مثل منافذ المكونات الإضافية Dev)
هل تستخدم الفرع المستقر؟ إذن هناك وقت طويل حتى الإصدار المستقر التالي، ولكن بخلاف ذلك لا تحتاج إلى انتظار إضافة الالتزامات إلى أحدث فرع بعد دمج طلب السحب.
أستخدم إعداد Docker لـ Discourse وقد طرحت اقتراحاً جيداً بخصوص الفرع، نعم، قد أتمكن من تغييره عند دمج طلب السحب (PR) وعدم الانتظار حتى الإصدار الفعلي.
بالنظر إلى app.yml، يمكنني رؤية أنه يستخدم إصدار (فرع) tests-passed، والذي بالنظر إلى GIT أفترض أنه ليس الأفضل للاستخدام من أجل الاستقرار. أي إصدار يُفضل استخدامه main أم التبديل إلى latest tag؟ هل من الممكن التبديل إلى علامة (tag) على الإطلاق لإعداد Docker؟
@david ، @Falco لقد أنشأت PR، يرجى مراجعته وإخباري إذا كان هناك أي شيء مفقود. أحتاج إلى تقدم هذا في أسرع وقت ممكن، لذا إذا تمكنت من تحديد أولوياته بطريقة ما، فسأكون ممتنًا جدًا.