سوليدوس أدمينلاند
هذه مرحلة ما قبل ألفا ويمكن تغييرها في المستقبل.
يبدأ هذا كمشروع ممتع للأغراض الداخلية لإنشاء نسخة أكثر موثوقية من لوحة الإدارة Solidus_backend. يحتوي Solidus على مكون أساسي رائع وواجهة إدارية متضمنة للبطارية، ولكن في رأينا وبسبب تخصيصاتنا، تفتقر جوهرة الإدارة إلى هيكل التصميم لكونها بنية تحتية جانبية حقيقية للتواصل مع بنية Solidus_core.
سمات
- جميلة وسهلة الاستخدام (تجربة المستخدم مهمة)
- يعمل بالطاقة هوت واير توربو ⚡️
- التحفيز باستخدام خرائط الاستيراد للتألقات الصغيرة
- أصبحت التصفية سهلة مع Ransack
- العمليات المجمعة مثل التدمير
لماذا إعادة كتابة العجلة؟
كما قلنا، في رأينا، يعتمد Solidus_backend على الكثير من التحذيرات من التمسك بالمكتبات التي تم اختيارها مرة أخرى إلى شوكة فورة (تشوه أنا أنظر إليك!) وهذا الشكل صارم للغاية بالنسبة لتلك الاختيارات:
- الكثير من المرشحات التي تحتوي على عمليات نهب أصبحت فوضوية مع ملخص المعلمات المخصص
- يمكن استخدامه مع "وحدات الماكرو" (:manage، :admin) وليس مع مسارات CRUD الحقيقية ولا يلتزم باتفاقيات نمط MVC.
- يعتمد تحرير المنتج والطلب والترويج على نظام ajax ذو العمود الفقري وليس على سلوك CRUD الأكثر تقليدية.
- غير متوافق مع التوربو "حقًا": تم تطوير الروابط التوربينية في الأسلاك الساخنة والاستخدام الحالي ليس سوى مقتطف لتنفيذ البرنامج النصي الصحيح لجافا سكريبت.
- الاستخدام المكثف لتنفيذ جافا سكريبت عن بعد لـ Rails-ujs و'remote: true' بدلاً من استجابة HTML أكثر وضوحًا وقابلية للتنبؤ باستخدام Turbo. أعتقد أن التحكم عن بعد ليس أسلوبًا جيدًا لأنه يقوم بإدخال كود جافا سكريبت في وحدة تحكم المتصفح على أمل أن يتم تنفيذه، وهو بالنسبة لي يمثل تهديدًا أمنيًا محتملاً للبرمجة النصية.
كما ترى، فإن Solidus_admin قديم جدًا، أما بالنسبة لتجديد Solidus_frontend باستخدام Solidus_starter_frontend، فقد حان الوقت لتجربة وتجديد مكثفين!
هل تحاول إنشاء جوهرة Solidus_backend جديدة؟
نوعاً ما ولكن لا . لقد بدأت هذا كمشروع بديل أولاً لأنه مشروع ألفا وهو الهدف الذي يجب أن يقدمه، إلى جانب بطارية مضمنة خلفية مع اقتران منخفض مع إطار عمل القضبان، ولكن أيضًا إطار عمل Adminland منظم جدًا لقابلية التوسع وتخصيص واجهة المستخدم دون أي عائق . أريد أن أجعل الأمر يعتمد بشكل أكبر على المكتبة المختارة من مالك المشروع المضيف، كتكامل سهل دون أن يكون صارمًا للغاية.
حسنًا، ما هو اختيارك؟ هل رأيك أيضًا قابل للرأي؟
أعتقد أننا يمكن أن نفكر في بنية كود adminland لتتوافق مع هذه الأساسيات:
- يكون من السهل تجاوزه ويمتد مع عدد أقل من التجاوزات/نهج التصحيح القرد. نحن بشر ولسنا قرد!
- الحظر المسبق لDeface. لم يعجبني أبدًا نهج التشويه وأعتقد أنه من الأفضل اعتبار واجهة المستخدم معيارية منذ البداية، في طرق عرض مهيمنة بديلة عن طريق النسخ ولكن ليس عن طريق التصحيح والحقن. من أجل قابلية توسيع أداة جانبية أخرى (جميع امتدادات Solidus مع أقسام الإدارة)، أفضّل إنشاء نقطة بادئة أكثر وضوحًا وكشفًا.
- صارمة لطرق CRUD. يجب أن يعتمد كل شيء على مسارات CRUD بأكبر قدر ممكن من الصرامة، كما هو الحال أيضًا مع نهج المسارات المتداخلة، لصالح التقليد بدلاً من نهج التكوين.
- يجب إضافة موارد خارجية من استضافة تطبيق Rails باستخدام قالب سقالة المولد.
مع أخذ ذلك في الاعتبار، بدأت في وضع بعض الاختيارات لمشروع Solidus_adminland "الجديد" مثل:
- hotwire افتراضيًا ويشجع على أكثر من مجرد أسلوب معالجة js DOM.
- التحفيز للإضافات البسيطة والموثوقة مثل المنتقيين وقناع الإدخال والتحقق من صحة النموذج
- استخدام جوهرة view_component لتغليف الأساليب المساعدة مع نتائج HTML (مثل link_to أو الأساليب الأكثر تعقيدًا). يعد أيضًا أسهل لغرض التجاوز، بدلاً من الأجزاء الجزئية من أجل الموثوقية وفئة PORO لمنطق واجهة المستخدم
- يتم إجراء كل عملية استيراد للأصول باستخدام Rails-importmap من أجل "لا يوجد نهج تطبيق يركز على جافا سكريبت"
- استخدام جوهرة الإدارة لتقسيم الاهتمام بين التمثيل (مع * فئة لوحة المعلومات) ومسارات CRUD لعرض البيانات أو إرسالها
- يتم تصميم كل النماذج بواسطة FormBuilder حيث يتم عرض كل حقل بفئة مكون منفصلة. إذا أردنا نحن أو أي شخص في الميزة وضع بعض الحقول الغريبة مثل حقول Dropdown JS، فيمكن إنشاؤها باستخدام Admininstrate::Field، FormBuilder::Component وتحفيز js sparkle الجديد؟
- بالنسبة لطريقة السياسة، أعتقد أنه يمكننا وضع نهج مختلط ليكون متوافقًا مع كانكان ولكن مع نهج أكثر سهولة. في حالتنا نستخدم جوهرة action_policy. إنها تعتمد على كائن PORO حيث يمكننا تحديد القاعدة التي يجب اتباعها لكل إجراء. إنها قطعة وسطية حقيقية لوحدات التحكم لسياسة التحكم في "نطاق السجل" و"سجل المعلمات المسموح بها" و"المسارات التي يمكن الوصول إليها بالسجل".
كما ترون، لكل مورد هناك:
- وحدة تحكم بنفس الاسم لعمليات CRUD القياسية
- لوحة معلومات بنفس الاسم للفهرس وnew_form وedit_form وإظهار المعلمات المراد عرضها
- سياسة للنطاق الذي يمكنني الوصول إليه مع المستخدم الحالي، والمعلمات التي يمكنني إرسالها، والطريق المسموح لي به لهذا المورد.
... وباعتباره نهجًا "تقليديًا"، يمكنك فقط إنشاء (أو توسيع) الخاص بك من هؤلاء الثلاثة ووضع منطق عملك كما تريد (أو متطلبات تطبيقك)!
تم إجراء التصميم الأولي باستخدام bootstrap 5 مع Tabler ولكن يمكنك بسهولة تجاوز طرق العرض القياسية من المسؤول/التطبيق لـ CRUD. سيبقى عدد المشاهدات محدودًا إلى أدنى مستوى ممكن
خريطة الطريق
تم الحصول على جميع حقوق الشعارات والألوان من Solidus presskit. موضوع المسؤول مستوحى من نماذج بالحجم الطبيعي لموقع Solidus ويستند إلى إصدار Bootstrap 5 من Tabler
