لقد رأيت مؤخرًا الكثير من المقدمات حول أطر عمل CSS، وقد قلت شيئًا ما قبل بضعة أيام: "في مجال رؤيتي المحدود، لم أر أي شيء يمكن تسميته حقًا بإطار عمل CSS ~". قد يكون مجال رؤيتي صغيرًا جدًا، أو العالم كبيرًا جدًا، وما زلت أشعر أنه لا يزال هناك الكثير من الأشياء التي لا أستطيع رؤيتها.
دعونا نلقي نظرة أولاً على المفهوم الذي أتفق معه:
يمكن تقسيم الإطار إلى نوعين: الصندوق الأبيض والصندوق الأسود.
تسمى الأطر المستندة إلى الميراث بأطر الصندوق الأبيض. يتمتع ما يسمى بالمربع الأبيض بالرؤية، وتفاصيل التنفيذ الداخلي للفئة الأصلية الموروثة معروفة للفئة الفرعية. يقوم مطورو التطبيقات الذين يستخدمون أطر عمل الصندوق الأبيض بتطوير الأنظمة عن طريق اشتقاق الفئات الفرعية أو تجاوز أساليب الأعضاء للفئات الأصلية. يعتمد تنفيذ فئة فرعية بشكل كبير على تنفيذ الفئة الأصلية، وتحد هذه التبعية من مرونة واكتمال إعادة الاستخدام. لكن طريقة حل هذا القيد هي وراثة الفئة الأصلية المجردة فقط، لأن الفئات المجردة في الأساس لا توفر تنفيذًا ملموسًا. إطار الصندوق الأبيض عبارة عن هيكل عظمي للبرنامج، والفئات الفرعية المشتقة من المستخدم هي ملحقات لهذا الهيكل العظمي.
الإطار الذي يعتمد على تجميع مكونات الكائن هو إطار عمل الصندوق الأسود. يحصل مطورو التطبيقات على تنفيذ النظام عن طريق فرز الكائنات وتجميعها. يحتاج المستخدمون فقط إلى فهم الواجهة الخارجية للمكون ولا يحتاجون إلى فهم التنفيذ الداخلي المحدد. بالإضافة إلى ذلك، يعد التجميع أكثر مرونة من الوراثة ويمكن تغييره ديناميكيًا، فالوراثة ليست سوى مفهوم ثابت لوقت الترجمة.
في الحالة المثالية، يمكن الحصول على أي وظيفة مطلوبة عن طريق تجميع المكونات الموجودة. في الواقع، المكونات المتاحة بعيدة كل البعد عن تلبية الاحتياجات. في بعض الأحيان يكون من الأسهل الحصول على مكونات جديدة من خلال الميراث بدلاً من تجميع مكونات جديدة باستخدام المكونات الموجودة. سيتم استخدام الصندوق الأبيض والصندوق الأسود في تطوير النظام في نفس الوقت. ومع ذلك، تميل أطر الصندوق الأبيض إلى التطور نحو أطر الصندوق الأسود، كما أن أطر الصندوق الأسود هي أيضًا الأهداف المثالية التي يأمل تطوير النظام في تحقيقها.
دعونا نلقي نظرة على العديد من أطر عمل CSS الموجودة على الإنترنت اليوم (تسمى YUI "أدوات CSS لمكتبة YUI" بدلاً من "أطر عمل YUI CSS"). ما عليك سوى تحديد الفئات الأساسية للنمط. وبطبيعة الحال، قد لا يكون فهم الجميع للإطار هو نفسه، وقد لا توافق على ما أقول.
لنتحدث عن إطار عمل CSS مرة أخرى، لا يعني ذلك أنني لا أدرك وجود هذا الشيء، فأنا أحاول القيام بمثل هذه الأشياء منذ عام أو عامين. بالنسبة لمواقع الويب الكبيرة، يتطلب تطوير الواجهة الأمامية حلاً. الإطار هو بطبيعة الحال الخيار الأول. من المؤسف أنه بعيد جدًا عني وأنا ضعيف جدًا T_T أحتاج فقط إلى شيئين:
شيء لإدارة المحتوى أدناه
الفئة/المكون
من الواضح أن النقطة الأولى هي أن CSS لا تستطيع القيام بذلك، والنقطة الثانية هي أنها ضعيفة جدًا مقارنة باللغات الأخرى.
عندما كنت أعمل على موقع ويب متوسط الحجم منذ حوالي عام، لكي أكون كسولًا، فكرت في تقسيم المحتوى إلى وحدات والسماح للمبرمجين بتجميع الصفحات معًا. الاتجاه العام هو تغليف كتلة وظيفية واحدة تلو الأخرى. يحتاج المبرمجون فقط إلى استخدام HTML وCSS المطابقين عندما يريدون استخدام أي جزء من المحتوى يناسب الجميع لا داعي لتكرار الكود، مرحباً بالجميع، إنه جيد حقًا.
على نفس موقع الويب، من الطبيعي أن يتم استخدام كتل محتوى مماثلة عدة مرات، وهذا أيضًا يجعل من الممكن إجراء عملية نمطية، مثل قائمة الصور، أو قائمة الصور الرمزية للمستخدم، أو قائمة أيقونات المجموعة هل يجب كتابة نفس الكلمات بهذه الطريقة؟
.photoListUesr,.photoListGroup{ /*_*/ }
هذا لا يعني أنه مستحيل، ولكن ماذا لو أردت فجأة إضافة شيء مماثل في هذا الوقت، قد تحتاج إلى تعديل النمط؟ ماذا عني حاولت استخدامه مثل هذا:
<div class="photoList UesrCt" />
<div class="photoList GroupCt" />
في هذه الحالة، نقوم بفصل التعبيرات الشائعة من البداية، واستخدام .photoList كنموذج أولي، والتعامل مع التفاصيل من خلال فئات إضافية. قبل بضعة أيام، كتبت عن برمجة XHTML وCSS الموجهة للكائنات، وفي الواقع، كتبت نصفها فقط، وكان النصف الآخر عبارة عن أمثلة تفصيلية، لكنني لم أنهيه لأنه كان علي أن أفعل الكثير من الأمثلة تمت كتابة النواة بالفعل ^^ بالطبع، هذا أيضًا به مشاكل معينة، أي أن تعريف النموذج الأولي يجب أن يكون حذرًا للغاية، ومحاولة التأكد من أنه حتى لو تمت مراجعته في المستقبل، فقد لا يكون هناك حاجة إلى ذلك. معدل. مع CSS، يمكن لإطار العمل أن يناسب موقع ويب واحدًا فقط على الأكثر. بالطبع، إذا كان موقع الويب كبيرًا بدرجة كافية، فمن المنطقي استخدامه بهذه الطريقة.
كلما أصبحت HTML وCSS أكثر معيارية، أصبحت الملفات أكثر تجزئة وأصبحت هذه المشكلة أكثر خطورة. من السهل التعامل مع HTML، حيث سيتم في النهاية دمج التطبيق وإخراج نسخة واحدة، ولكن عادة ما يتم تجاهل CSS واستخدامه مباشرة. إذا كانت طريقة استيراد CSS إلى صفحة الويب في المثال الآن هي كما يلي:
@import url(/xxx/photoList.css);
@import url(/xxx/UserCt.css);
@import url(/xxx/GroupCt.css);
يمكنك أيضًا التفكير في استخدام برنامج لدمج الصفحات، ولكنه سهل الاستخدام ويتناسب مع عدد الطلبات. بشكل عام، سيختار الجميع دمج الملفات يدويًا. على الرغم من أن الدماغ البشري أكثر ذكاءً من الكمبيوتر، إلا أن القدرة الحاسوبية للدماغ البشري في كثير من الحالات ليست جيدة مثل قدرة الكمبيوتر. خطرت لي فكرة استخدام برنامج من جانب الخادم للتعامل مع آلية إصدار CSS. الاتجاه العام هو تحليل استخدام الصفحات المختلفة للموقع بأكمله من خلال سجلات الوصول إلى موقع الويب، واستخدام البرنامج لحساب الاستخدامات العامة. يجب دمجها بالترتيب (سيؤثر ترتيب ملفات CSS على الأولوية)، وما إلى ذلك. حسابات مختلفة ومخرجات مضغوطة.
ولسوء الحظ، فإن مثل هذا البرنامج المعقد قد يكون مناسبًا فقط لمحطة واحدة، أو لمجموعة من المحطات في نفس السلسلة. على الرغم من أن القيام بذلك أمر مزعج بعض الشيء، إلا أنني أعتقد أنه من الضروري استخدام هذه الطريقة لمواقع الويب على مستوى البوابة. وبطبيعة الحال، فإن الفرضية هي أن الفريق بأكمله يجب أن يستخدم نفس نمط التصميم.
ملحوظة: برنامج النشر CSS أعلاه هو مجرد خيالي، ولم أجربه بعد، ويمكن للأصدقاء المهتمين تجربته، ولن أتحمل المسؤولية.
بالطبع، لا يمكن تسمية ما ورد أعلاه بإطارات عمل CSS، وربما يمكن تسميته فقط بحل على مستوى النظام، لأن CSS هي مجرد لغة وصفية.
عندما كنت أتناول البط المشوي مع Yueying الليلة الماضية، تحدثنا عن هذا الأمر وسألني إذا كان لدي حل أمامي متكامل. سيتم مواجهة نفس المشكلة عندما يتم تقسيم JS إلى مكونات، وينبغي أيضًا تطبيق آليات نشر مماثلة على JS. لكنني لم أفكر في حل متكامل تمامًا حتى الآن، ربما ستعاملني Yueying بشوي البط عدة مرات أخرى ويمكنني اكتشاف ذلك.