لوحة المتصدرين

أصبحت واجهات REST البرمجية أكثر انتشارًا بين المطوّرين، نظرًا لأنها توفّر واجهة بسيطة، موحّدة وواضحة لخدمات الطرف الثالث third-party مثل Twitter، MailChimp وGitHub. ومع ازدياد شهرة واجهة ووردبريس البرمجية (المتوفرة عبر إضافة) فإن الوقت قد حان لنتعلم حول واجهة HTTP البرمجية في ووردبريس، وكيفية عملها واستخداماتها. ما هي واجهة HTTP في ووردبريس؟ لن يكون من المستغرب القول بأنها طريقة لإرسال واستقبال الرسائل بواسطة HTTP – لغة شبكة الويب. حيث يقوم المتصفح بإرسال واستقبال الرسائل طوال الوقت وبهذا الشكل يتم استقبال صفحات الويب. ويمكن من خلال واجهة REST البرمجية، يمكن باستخدام رسائل HTTP القيام بأشياء أكثر كتعديل منشور، حذف حساب مستخدم أو نشر وصفة جديدة على موقعك. لهذا السبب تعتبر واجهة ووردبريس البرمجية مهمة جدًا، فهي تسمح بفصل التطبيق من جهة المستخدم عن النواة البرمجية الخاصة بووردبريس. ولاستخدامها، تحتاج أن تكون معتادًا على إرسال طلبات HTTP واستقبال الأجوبة، وهذا هو أساس عمل واجهة HTTP البرمجية. وهناك العديد من الطرق لإرسال طلبات HTTP، حيث توفّر واجهة HTTP البرمجية طريقة موحّدة باستخدام مجموعة من التوابع المساعدة والتي سنطّلع عليها بعد قليل. طرق HTTP ومصادرها ترتكز HTTP حول الطرق methods (تسمّى أحيانًا بالأفعال verbs) والمصادر resources. تحدّد المصادر العنصر الذي سيتم تنفيذ العملية عليه، وتحدّد الطريقة نوع العملية التي سيتم تنفيذها. ويعتبر العنوان URL هو المصدر الذي يشير إلى الغرض على شبكة الويب، كمنشور على سبيل المثال. وتوجد العديد من الطرق، لكن الأهم فيها هي GET, POST, PUT و DELETE. ولا بد أن لديك الكثير من الخبرة مع GET فهذه الطريقة هي المستخدمة في الحصول على المصادر، فمثلًا عند استعراض مقال في المتصفح يتم إرسال طلب GET إلى عنوان المقال وليكن مثلًا https://premium.wpmudev.org/blog/using-the-wordpress-http-api/. أما طلبات PUT فتستخدم لتعديل المصادر، وتستخدم طلبات POST لإنشاء مصادر جديدة، وتستخدم طلبات DELETE لحذف مصادر موجودة مسبقًا. ولو كان لدى موقع WPMU DEV واجهة REST برمجية، فربما كان من الممكن أن يقوم المدير بإرسال طلب DELETE لحذف المقال على الرابط https://premium.wpmudev.org/blog/wordpress-http-api، وهذا الأمر مفيد جدًا للمواقع الكبيرة التي تملك برامج إدارة على الهواتف الذكية. مثال عن طلب HTTP بسيط للقيام بإرسال طلب GET بسيط على سبيل التجربة، سنقوم باستخدام التابع wp_remote_get() الذي يملك مُعاملين، المُعامل الأول هو رابط المصدر، والمُعامل الثاني هو مصفوفة اختيارية optional من الخيارات التي من الممكن استخدامها لتحديد بعض التفاصيل. $test = wp_remote_get( 'http://google.com' ); echo "<pre>"; var_dump($test); echo "</pre>"; يقوم المثال السابق بجلب الصفحة الرئيسية لموقع جوجل، ومن ثم يتم طباعة محتوى المتغير test الذي يحوي على جواب الطلب الذي أرسله موقع جوجل – حيث يمكن رؤية جميع العناصر التي يحتويها. تحتوي الترويسات headers على المزيد من المعلومات عن كل رسالة. وقد تطلب منك بعض واجهات REST البرمجية أن تقوم بإرسال معلومات محددة في الترويسات عندما ترسل الطلب. يحتوي الجواب response على رمز الحالة status code وعبارة قد تكون معروفة بالنسبة لك كأخطاء 404، أو خطأ في معالجة الطلب 500 أو تحويل من النوع 301 أو 302. يحتوي موقع W3.org على جميع رموز أخطاء HTTP المعرّفة والمشروحة، ويعتبر مصدرًا مفيدًا إن احتجت أن تعرف ما يعني أي خطأ. بإمكانك أيضا الاطّلاع على هذا المقال على أكاديمية حسوب لتعرف المزيد حول هذه الرّموز: رموز الإجابة في HTTP يحتوي الجسم body على الجواب وهو المكان الذي تحتاج أن تنظر إليه بحثًا عن النتيجة المطلوبة. في حالة المثال السابق، فإننا نحصل على وسوم HTML التي تشكّل الصفحة الرئيسية، ولكن عند التعامل مع واجهات REST البرمجية فمن الشائع أن نحصل على نص بصيغة JSON. وعادة ما تطلب الواجهات البرمجية APIs أن يتم إضافة نص محدّد إلى الجسم عند إرسال طلبات أيضًا. يحتوي قسم cookies على أي كعكات تم استلامها مع الرسالة. كما ترى، فإن إرسال طلب باستخدام واجهة HTTP البرمجية أمر بسيط جدًا. ما يجعل العمل مع HTTP معقّد نوعًا ما هو أن واجهات REST البرمجية قد تكون حساسة جدًا لصيغة البيانات المدخلة (وهو أمر جيّد) لذا فإن تجاوزت سطرًا عند دراسة توثيق الواجهة البرمجية قد ينتهي بك الأمر ببرمجية لا تعمل كما ترغب. العمل مع الواجهات البرمجية أعتقد بأنه من الآمن القول بأن معظمكم سيستخدم HTTP للتعامل مع واجهات REST البرمجية في شبكة الويب، وفي هذه الحالة سنحتاج لاستخدام المعامل الثاني لتحديد بعض الأمور، كالاستيثاق وتجنب بعض الأخطاء الشائعة. لنبدأ بمثال بسيط – استعادة البيانات من لوحة Pinterest. تتطلب جميع الواجهات البرمجية الجيّدة تنفيذ عملية استيثاق للتعريف عن المستخدم الذي يرسل الطلب، لكنّنا سنغش قليلًا في هذا المثال باستخدام مولّد رموز الأمان الخاص بـ Pinterest. بعد إكمال الاستيثاق ستحصل على رمز أمان يمكن استخدامه في المثال التالي، حيث سنقوم بإنشاء طلب لجلب وعرض قائمة بمنشورات Pinterest. $request = wp_remote_get( 'https://api.pinterest.com/v1/boards/marticz/home-office/pins/?access_token=<your access token>' ); $pins = json_decode( $request['body'], true ); if( !empty( $pins['data'] ) ) { echo '<ul>'; foreach( $pins['data'] as $pin ) { echo '<li><a href="' . $pin['url'] . '">' . $pin['note']. '</a></li>'; } echo '</ul>'; } لو قمنا بنسخ المثال السابق ولصقه في صفحة content-page.php في قالب Twenty Fifteen لتجربته فإن النتيجة هو الحصول على لائحة بالمنشورات من لوحة Pinterest حول المكاتب الشخصية في المنزل. لا تنس أن تستبدل <your access token> في المثال السابق برمز الأمان الذي حصلت عليه. يقوم السطر الثاني في المثال بفك ترميز جسم الجواب من JSON إلى شكله الأساسي كمصفوفة ونقوم بإنشاء حلقة loop تقوم بطباعة محتوى عنصر المصفوفة $pins['data']. الاستيثاق يقع العديد من الأشخاص في عثرات في هذه المرحلة لأنها تتطلب خطوة إضافية على الأقل وربما بعض الترويسات الإضافية أيضًا. ولننظر إلى واجهة تويتر البرمجية على سبيل المثال، وتحديدًا إلى الاستيثاق الخاص بالتطبيقات، الذي يمكنك استخدامه لاستيثاق تطبيقك مع تويتر. قراءة التوثيق إن أول خطأ قد يتم ارتكابه هو عدم قراءة التوثيق بشكل جيّد. ولو كنت مبرمجًا متمرسًا في واجهات REST البرمجية فيمكنك القفز مباشرة إلى الجزء حول الاستيثاق، ولو فعلت هذا فقد لا تنتبه إلى سطر يقول: وإهمال هذا الشرط سيؤدي إلى فشل حتمًا في الحصول على نتيجة، على الرغم من أن كل شيء آخر مطبّق بشكل كامل، لذا حتى توفّر على نفسك الحاجة لمراجعة شفرة برنامجك، تأكد من قراءة التوثيق بشكل جيّد وكامل. إضافة ترويسات ومعاملات أخرى بعد اتباع التوجيهات في التوثيق حرفيًّا، قمت بإنشاء طلب POST، ينبغي أن يؤدي إلى توليد رمز أمان للوصول من أجلي، ويبدو الكود على الشكل: $key = base64_encode( urlencode( "n8KP16uvGZA6xvFTtb8IAA:i4pmOV0duXJv7TyF5IvyFdh5wDIqfJOovKjs92ei878" ) ); $request = wp_remote_post('https://api.twitter.com/oauth2/token', array( 'headers' => array( 'Authorization' => 'Basic ' . $key, 'Content-Type' => 'application/x-www-form-urlencoded;charset=UTF-8' ), 'body' => 'grant_type=client_credentials', 'httpversion' => '1.1' )); $token = json_decode( $request['body'] ); echo "<pre>"; var_dump($token); echo "</pre>"; إن الخطوة الأولى هو ترميز رمز أمان الوصول والكلمة السرّية بصيغة URL encoding. قمت أيضًا بإضافة ترويستين، واحدة ترويسة استيثاق تحوي على بيانات الوصول. أما الترويسة الثانية فهي ترويسة نوع المحتوى content type، والتي يطلب توثيق تويتر إضافتها. إضافة لما سبق، قمت بملء جسم الطلب تمامًا كما ذكرت الملاحظة السابقة حول grant_type=client_credentials وتم إضافة إصدار HTTP كما يطلب توثيق تويتر أيضًا. سيحتوي الجواب بالإضافة للعديد من المعلومات الأخرى على رمز أمان الوصول في جسم الجواب، وسنحتاج لرمز الأمان هذا في جميع الطلبات اللاحقة المرسلة إلى الواجهة البرمجية الخاصة بتويتر. تخزين رمز أمان الوصول إن رمز الأمان صالح لبعض الوقت، ويعتبر طلبه مجدّدًا هدرًا غير ضروري عند تحميل كل صفحة أو عندما يحتاج تطبيقك أن يقوم بعملية ما وسيؤدي إلى استهلاك عدد الطلبات المسموح بسرعة. يمكن في ووردبريس استخدام عابرة transient لتخزين قيمة رمز الأمان ومن ثم استخدام العابرة عند كل طلب لاحق للواجهة البرمجية. $token = get_transient( 'twitter_access_token' ); $token = ( empty( $token ) ) ? get_twitter_access_token() : $token; $request = wp_remote_get('https://api.twitter.com/1.1/followers/ids.json?screen_name=danielpataki&count=5', array( 'headers' => array( 'Authorization' => 'Bearer ' . $token, 'Content-Type' => 'application/x-www-form-urlencoded;charset=UTF-8' ), 'httpversion' => '1.1' )); $token = json_decode( $request['body'] ); سيؤدي إرسال الطلب السابق إلى واجهة تويتر البرمجية إلى عرض 5 من متابعيّ على تويتر (قائمة بسيطة لأرقام حساباتهم Ids). وكما يظهر في المثال السابق، فإنني أقوم بجلب القيمة التي خزّنتها في العابرة فإن لم تكن موجودة سأقوم باستدعاء التابع get_twitter_access_token() للحصول على رمز أمان جديد ومن ثم إضافته إلى العابرة كي أستخدمه في الطلبات اللاحقة. تجدر الإشارة إلى أن هذه الطريقة تهدف فقط إلى إظهار آلية التنفيذ وليست أفضل طريقة للتنفيذ، وكسيناريو أبسط كنت لأقوم بوضع جميع العبارات الشرطية IFs داخل التابع get_twitter_access_token() الذي سيقوم بتنفيذ جميع الشيفرة السابقة ضمنيًا. التوابع المساعدة في واجهة HTTP البرمجية الآن وبعد أن حصلنا على لمحة جيدة حول هدف المقال، دعونا نلق نظرة على التوابع التي ستساعدك في واجهة HTTP البرمجية في ووردبريس. هناك 4 توابع يمكن بواسطتها تنفيذ طلبات: wp_remote_get() wp_remote_post() wp_remote_head() wp_remote_request() ومن الواضح تمامًا وظيفة كل تابع، أما التابع الأخير wp_remote_request() فهو تابع عام يمكنك استخدامه مع أي طريقة HTTP method. أما التوابع الخمسة التالية فتسمح لك بالحصول على جواب على الطلب بسهولة باستخدام توابع قياسية عوضًا عن الخوض في التعامل مع المصفوفات وعناصرها. wp_remote_retrieve_body() wp_remote_retrieve_header() wp_remote_retrieve_headers() wp_remote_retrieve_response_code() wp_remote_retrieve_response_message() أيضًا يبين اسم كل تابع الهدف الوظيفي له بسهولة، وينصح عند الإمكان باستخدام هذه التوابع عوضًا عن التعامل مع المصفوفات يدويًا، حيث ستسمح هذه الطريقة الموحّدة لمطوّرين آخرين بفهم البرمجية بسهولة واستخدام الخطافات hooks إن أصبحت متاحة في المستقبل. الخلاصة كما ترى فإن التعامل مع واجهة REST البرمجية سهل باستخدام واجهة HTTP البرمجية في ووردبريس وبعض توابع ووردبريس كالعبّارات. أنصح بشدّة تجربة هذا الأمر لأن عملية التطوير في ووردبريس تسير بثقة باتجاه العالم المُقاد باستخدام الواجهات البرمجية وعليك أن تقفز إلى الموكب قبل فوات الأوان. إن كان لديك المزيد من الأسئلة حول استخدام واجهة HTTP البرمجية أو لديك بعض الأفكار حول كيفية استخدامها، فلا تتردد بمناقشة الأمر في قسم التعليقات في الأسفل. ترجمة -وبتصرّف- للمقال How to Use the WordPress HTTP API لصاحبه Daniel Pataki.

لم يعد إنشاء تصاميم متجاوبة اختياريًّا، فلقد أصبحت شبكات CSS وعلى نحو سريع الخيّار المفضّل لإنشاء بنى منسجمة لمواقع ويب تبدو بمظهر رائع على مختلف أنواع الأجهزة. تزوّدنا شبكات CSS بطريقة سريعة لبناء أيّ موقع. فلا بدّ أن تكون قد عانيت مع خصائص التموضع والتعويم float في CSS من قبل. كل هذه المعاناة ستنتهي مع شبكات CSS. تجعل شبكات CSS3 من عمليّة إنشاء وتعديل موقع، شيئًا يسيرًا للغاية. سنتعلّم كيف تعمل هذه الشبكات ولماذا ينبغي علينا استخدامها، وكيف ننشئ شبكاتنا الخاصّة بنا لبناء layouts مُخصّصة. ما هو نظام شبكة CSS؟ قبل أن نبدأ بإنشاء بنية خاصّة بنا، هناك بعض الأمور التي نحتاج أن نعرفها مسبقًا. لإنشاء مخطّط لموقع ويب جديد نبدأ أولّا بشبكة. ستحتوي هذه الشبكة الأساسيّة على أسطر rows وأعمدة columns وخلايا cells ومسارات tracks وخطوط lines ومناطق areas. هناك أيضًا عناصر الشبكة وهي بشكل أساسي عبارة عن المحتوى الذي نضعه ضمن الشبكة. تشبه الشبكة الجدول من ناحية الإظهار. ولكن يكمن الفرق الكبير بينهما في وجود خصائص مُحدّدة وقويّة متاحة ضمن شبكة CSS، سنتحدّث عنها بعد قليل. تحمل الأسطر والأعمدة والخلايا نفس المعنى في كلّ من شبكات CSS وجداول HTML العاديّة. أمّا المسار track فهو عبارة عن سطر كامل أو عمود كامل. المسار track في الشبكة، عبارة عن سطر كامل أو عمود كامل. وبالنسبة للمنطقة فهي مكوّنة من خلايا تشكّل حاويةً مستطيلة الشكل للمحتوى، في حين أنّ خطوط الشبكة grid lines هي الفواصل بين الخلايا في البنية الشبكيّة، وهي تشبه على أية حال حدود الخلايا في جداول HTML العاديّة. تشكّل المناطق مقاطع بنيويّة ذات طبيعة متنوّعة، مثل المناطق الخاصة بالعنوان header والشريط الجانبي sidebar والمحتوى الأساسي والتذييل footer. تشكّل المنطقة area مقاطع بنيويّة متنوّعة في الشبكة. بتعريف هذه المناطق باستخدام شيفرة CSS الجديدة المتاحة، يمكننا إنشاء وتنسيق البنية الشبكيّة المطلوبة، بنفس السرعة التي تحتاجها لإنشاء بنية جدوليّة قديمة، ولكن بمزايا قابلية التعديل والتغيير بسهولة أكبر بكثير. المشكلة الوحيدة في شيفرة CSS الجديدة هي أنّها حتى هذه اللحظة ليست متوافقة بشكل كامل مع جميع المتصفّحات، ولكن تبقى مسألة وقت قبل أن تصبح قياسيّة في المدى القريب، بحيث تعمل على جميع المتصفّحات الأساسيّة المعاصرة. يمكنك تجربة مزايا الشبكة الجديدة مع جميع المتصفّحات من خلال إضافة يمكن الحصول عليها من هنا. يمكننا في متصفّح Chrome تفعيل منصّة الويب التجريبيّة experimental web platform بكتابة العنوان التالي في شريط عنوان المتصفّح: Chrome://flags انتقل إلى الأسفل حتى تصل إلى قسم تفعيل مزايا منصّة ويب التجريبيّة Enable Experimental Web Platform features ثم انقر Enable تحت العنوان. يمكننا اختبار شبكات CSS3 في متصفّح Chrome بإجراءات بسيطة. انقر بعد ذلك زر إعادة التشغيل الآن Relaunch Now وهذا كلّ شيء. أصبحنا الآن مستعدّين لتجربة شبكات CSS في Chrome ضمن أنظمة تشغيل Windows و Mac و Linux وحتى أجهزة Android. إعداد الشبكات باستخدام HTML5 الآن وبعد تفعيل الأدوات التجريبيّة، يمكننا البدء بإنشاء البنية الشبكيّة. نحتاج إلى صفحة لاختبار تأثيرات شيفرة CSS، انشأ ملف index.html. نحن مستعدّون الآن لإضافة شيفرة HTML5 أساسيّة لعرض أي شبكة ننشئها بعد قليل. سننشئ منطقة خاصّة بالعنوان header وأخرى خاصّة بالتذييل footer بالإضافة إلى منطقة خاصّة بالمحتوى content ومنطقة للشريط الجانبيّ sidebar على الجانب الأيمن من الصفحة. لنضيف الشيفرة التاليّة إلى الصفحة: <div id="grid"> <div class="header"></div> <div class="sidebar"></div> <div class="content"></div> <div class="footer"></div> </div> يمكننا وبشكل اختياري أن نضيف محتوى إلى كلّ قسم من الأقسام السابقة إذا أردنا أن نرى أين ستظهر الشبكة بعد الانتهاء. تنسيق الشبكة بشيفرة CSS قبل أن نبدأ بتنسيق الشبكة يجب أن نعلم أنّ هناك بعض تنسيقات CSS لا تعمل مع الشبكات: الخصائص column-* أي جميع الخصائص التي تبدأ بـ column- مثل column-span و column-width و column-rule. الخاصيّة float، وهذه الخاصيّة يمكن استخدمها إذا طبّقتها قبل تطبيق الخاصيّة display التي تُعيّن طريقة العرض إلى شبكة كما سنرى بعد قليل. لن يكون بالإمكان تعويم float المحتوى داخل الشبكة. الخاصيّة clear، حيث أنّه بمجرّد العمل مع بنى الشبكات فلا داعي لاستخدام هذه الخاصيّة لأنّ الشبكة تتجاهلها. الخاصيّة vertical-align، لا تمتلك هذه الخاصيّة أي تأثير على بنية الشبكة. العنصرين الزائفين first-line:: و first-letter:: لا يمكن تطبيقهما ضمن الشبكة. بالنسبة لأي خاصيّة CSS غير موجودة في القائمة السابقة فيمكن استخدامها مع الشبكات. قم بإنشاء الملف style.css لنعمل على تطبيق بنية الشبكة على التصميم. سنبدأ الآن باستخدام مُحدّد معرّف العنصر كما يلي: #grid { display:grid; } إذا وجدت أنّ تموضع الشبكة ليس مناسبًا، جرّب تغيير الخاصية السابقة لتصبح display:inline-grid حيث يؤدي ذلك إلى إنشاء البنية ضمن المنطقة التي تعمل ضمنها بدلًا من إنشاء حاوية مُخصّصة كما تفعل القيمة block عند استخدامها. نلاحظ أنّ الشبكة قد تمّ إنشائها ولكنّها فارغة. لإنشاء الخلايا يمكننا استخدام grid-template-rows و grid-template-columns بحيث نضعهم أسفل الخاصيّة display التي عرّفناها قبل قليل. القيم التي يمكن تزويدها لهاتين الخاصيّتين هي قيم أحجام الخلايا التي نرغب بإنشائها. فمثلًا إذا عرّفنا قيمة حجم واحدة من أجل سطر ما، فسيؤدّي ذلك إلى إنشاء سطر واحد فقط، في حين يؤدّي تعريف خمس قيم حجم إلى إنشاء خمسة أسطر. ويمكن تطبيق نفس الأسلوب على الأعمدة. فلإنشاء البنية السابقة المقترحة، يمكننا تعريف الأسطر والأعمدة على الشكل التالي: #grid { display:grid; grid-template-rows:100px auto 100px; grid-template-colums:repeat(9, 100px); } أنشأنا في المثال السابق ثلاثة أسطر وتسعة أعمدة. يبلغ ارتفاع السطر الأوّل 100 بيكسل، أمّا السطر الثاني فسيتم ضبطه تلقائيًّا بحيث يلائم المحتوى المُضاف بالنسبة إلى الشبكة، وسيبلغ ارتفاع السطر الثالث 100 بيكسل أيضًا. تسمح لنا الدالّة repeat بإنشاء أي عدد من الأعمدة أو الأسطر طالما أردنا أن يكون لها نفس القياس. في مثالنا هذا سننشئ تسعة أعمدة بعرض 100 بيكسل لكلٍّ منها. يبدو للوهلة الأولى أنّنا أضفنا عددًا عشوائيًّا من الأعمدة، خصوصًا أنّه لدينا خمس مناطق areas في البنية التي خطّطنا لها مسبقًا. تكمن الإجابة على ذلك أنّه بإمكاننا أن نجعل المناطق تمتد span على أكثر من خليّة، ويسمح لنا ذلك بضبط الحجم الافتراضي لكلّ منطقة بشكل فعّال. في مثالنا هذا ومن أجل سطر واحد يمكن أن تمتدّ المنطقة التي تضمّ المحتوى الرئيسي عبر سبعة أعمدة بحيث يبلغ العرض الافتراضي لها 700 بيكسل، كما يمتدّ الشريط الجانبيّ عبر عمودين ليصبح عرضه 200 بيكسل، وهكذا نحصل على عرض إجمالي قدره 900 بيكسل. لاحظ أنّه كان بإمكاننا تعريف عدد أقل من الأعمدة بعرض أكبر لكلّ منها، ولكننا لم نفعل ذلك. يكمن السبب في أنّه عند استخدام عدد أعمدة أكبر بعرض أصغر لكلّ منها، فإنّ ذلك سيؤدّي إلى تحكّم أكبر في عرض المناطق الممتدة على تلك الأعمدة، وخاصةً التي تحتاج إلى عرض قليل نسبيًّا مثل المنطقة التي نضع فيها حقوق التأليف والنشر مثلًا. تُطبّق نفس الفكرة تمامًا من أجل الأسطر، لكن لاحظ بأنّنا قد اخترنا عددًا قليلًا منها ممّا لا يمنحنا نفس المرونة المتوفّرة بالنسبة للأعمدة. على العموم لا بأس في ذلك، فهدفنا هنا هو تحقيق الفكرة والتعلّم حول الإمكانيّات المتوفّرة لتخطيط البنية الشبكيّة. لا تبدو الأمور حتى الآن كما هو مخطّط لها، لكن بمجرّد تعريف وتسمية مناطق الشبكة ستأخذ البنية الشبكيّة الشكل المطلوب. لتسمية المناطق فإنّنا نعيّن اسم المنطقة لكلّ عمود وسطر ستمتدّ عليه هذه المنطقة. يمكننا استخدام الخاصيّة grid-template-areas بحيث نضعها أسفل الخاصّتين المسؤولتين عن تعيين عدد الأسطر والأعمدة الّلتين أضفناهما قبل قليل، أي على النحو التالي: #grid { display:grid; grid-template-rows:100px auto 100px; grid-template-colums:repeat(9, 100px); grid-template-areas: "header header header header header header header header header" "content content content content content content content sidebar sidebar" "footer footer footer footer footer footer footer footer footer"; } نلاحظ من السطر الأوّل أنّ المنطقة header تمتدّ على كامل الأعمدة، وكذلك الأمر بالنسبة للمنطقة footer على السطر الثالث. أمّا السطر الثاني فسيحتوي على منطقة المحتوى الرئيسي main بالإضافة إلى منطقة الشريط الجانبي sidebar. حتى هذه اللحظة لم يتم إنشاء الشبكة بعد. في الحقيقة تُشير الأسماء المعرّفة توًّا: header و content و sidebar و footer إلى أسماء أصناف CSS سنعرّفها بعد قليل. بحيث نستخدم خصائص جديدة مع هذه الأصناف تُشير إلى بداية ونهاية كل منطقة بالنسبة للأسطر: grid-row-start و grid-row-end وبالنسبة للأعمدة: grid-column-start و grid-column-end. يمكن إضافة أصناف CSS هذه مباشرةً بعد شيفرة الشبكة السابقة: .header { grid-row-start:1; grid-row-end:2; grid-column-start:1; grid-column-end:10; } .content { grid-row-start:2; grid-row-end:3; grid-column-start:1; grid-column-end:8; } .sidebar { grid-row-start:2; grid-row-end:3; grid-column-start:8; grid-column-end:10; } .footer { grid-row-start:3; grid-row-end:4; grid-column-start:1; grid-column-end:10; } .content { grid-row-start:3; grid-row-end:4; grid-column-start:1; grid-column-end:7; } تُحتسب المناطق اعتبارًا من خطّ البداية (سطر أو عمود) إلى الخطّ الذي يلي خطّ النهاية الفعليّ حتى ولو لم يكن هذا الخط موجودًا، فإذا لم نأخذ هذا الأمر بعين الاعتبار، فمن الممكن إسناد نفس القيمة للبداية وللنهاية لمنطقة ما وبالتالي لا تظهر هذه المنطقة أبدًا. بهذا نكون قد انتهينا من إعداد الشبكة ويمكن البدء بإضافة التنسيقات المرغوبة. الأمر السلبيّ الوحيد في التصميم السابق أنّه ليس متجاوبًا مع شاشات الأجهزة المحمولة. جعل البنية متجاوبة مع الأجهزة المحمولة وفقًا لهذا التقرير فإنّ أكثر من نصف مجموع الأوقات التي قضاها المستخدمون على الانترنت في النصف الأوّل من عام 2015 كانت على الأجهزة المحمولة. وهذا يزيد بمقدار 11% عمّا كان عليه الوضع في العام السابق ويزيد بمقدار 39% عمّا كان عليه في عام 2008. من الملاحظ أنّ عدد الساعات التي يتمّ قضائها على الأجهزة المحمولة في ازدياد مطّرد، فإن لم نجعل موقعنا متجاوبًا مع هذه الأجهزة فسيفوتنا القطار! قد تبدو هذه العمليّة صعبة للوهلة الأولى، ولكنّ الأمر ليس بهذه الصعوبة. يوجد أسلوب أساسيّ يمكن من خلاله جعل البنية الشبكيّة متجاوبة، حيث يمكن باستخدام القاعدة media@ والخاصيّتان max-width و min-width أن نسمح للمتصفّح بعرض محتوى مناسب إذا استُخدم الجهاز المحمول لعرض الموقع. يمكن باستخدام القاعدة media@ تعريف أنماط تنسيق مُحدّدة للموقع بحيث تُطبّق عند استعراض هذا الموقع ضمن شاشة الجهاز المحمول. تسمح الخاصيّة max-width بشكل عام لأيّ عنصر بالالتزام بقياس مُحدّد عن طريق إسناد العرض الأعظمي للمنطقة التي يُسمح للمحتوى الخاص به أن يشغلها. تخبر هذه الخاصيّة موقعنا بأنّه من الممكن أن ندع محتويات المناطق تكبر أو تصغر طالما أنّها لا تتجاوز القيمة التي حدّدناها ضمن الخاصيّة max-width. أمّا عند استخدام الخاصيّة max-width مع القاعدة media@ فسيكون للخاصيّة max-width دور جديد وهو تحديد شرط لتطبيق أنماط تنسيق مُحدّدة عندما يتم استخدام شاشات صغيرة، كشاشات الأجهزة المحمولة. وينطبق نفس الأسلوب تمامًا على الخاصيّة min-width عند استخدمها مع القاعدة media@. الآن لنضع القاعدة التالية أوّل تنسيقات CSS التي أضفناها إلى ملف التنسيق: @media (max-width:900px) and (min-width:500px) { /* Your grid layout code goes here */ } ستُطبّق التنسيقات الموجودة ضمن القاعدة media@ عندما يُستخدم أيّ جهاز يتراوح عرض شاشته بين 900 بيكسل (العرض الأعظمي max-width) و500 بيكسل (العرض الأصغري min-width). لا ننسى بالطبع تعديل هذه القيم بما يتلاءم مع احتياجاتنا. التغييرات البسيطة في البنية لنضع الآن جميع التنسيقات مع بعضها البعض، ونضيف المزيد منها إلى البنية الجديدة. الشكل النهائي لملف تنسيقات CSS سيبدو مشابهًا لما يلي: @media (max-width:900px) and (min-width:500px) { #grid { display:grid; grid-template-rows:100px auto 100px; grid-template-colums:repeat(9, 100px); } } .header { grid-row-start:1; grid-row-end:2; grid-column-start:1; grid-column-end:10; } .content { grid-row-start:2; grid-row-end:3; grid-column-start:1; grid-column-end:8; } .sidebar { grid-row-start:2; grid-row-end:3; grid-column-start:8; grid-column-end:10; } .footer { grid-row-start:3; grid-row-end:4; grid-column-start:1; grid-column-end:10; } .content { grid-row-start:3; grid-row-end:4; grid-column-start:1; grid-column-end:7; } وهنا صورة تمثيليّة لما سنحصل عليه ضمن المتصفّح: صورة تمثيليّة للشكل الناتج يتألّف من ترويسة ومنطقة محتوى رئيسيّة وشريط جانبي ومنطقة للتذييل. إذا أردنا في أيّ وقت تعديل البنية الشبكيّة السابقة، فكل ما علينا فعله هو إعادة تعريف المناطق بتغيير مواقع البداية والنهاية لها لنحصل على الشكل المرغوب. وهذا يساعدنا على الانتقال إلى أيّ شكل جديد دون الحاجة لإعادة تصميم الصفحة بشكل كامل. توجد هناك تقنيّات متقدّمة يمكننا استخدمها لإضافة المزيد من المزايا إلى هذه البنية، يمكننا كما هو متوقّع استخدام تنسيقات CSS المألوفة لإكساب بنيتنا الجديدة تنسيقات جميلة وجذّابة. خاتمة نحن مستعدّون الآن لاستخدام آخر التحسينات في عالم CSS، يمكننا الآن فهم وإنشاء عناصر جديدة ومختلفة وتجميعها معًا لتشكيل بنية شبكيّة. أنصح بمراجعة وثائق العمل الحاليّة الخاصّة بالبنية الشبكيّة، وبشكل دوريّ، للاطّلاع على آخر المستجدّات حالما تصدر. ترجمة -وبتصرّف- للمقال Understanding CSS Grids for Modern WordPress Website Design لصاحبته Jenni McKinnon.

مبدأ عكس التابعيّة Dependency Inversion Principle أو اختصارًا DIP، هو آخر مبادئ التصميم الكائنيّ SOLID ويتمتّع بمزايا كبيرة عند تطبيقه بالشكل السليم. أوّل من قدّم هذا المبدأ هو روبرت مارتن في مقالته التي نشرها عام 1996. أشار روبرت إلى أنّ الأسلوب الشائع في تصميم التابعيّة dependency ضمن المشاريع البرمجيّة في جعل الوحدات البرمجيّة عالية المستوى تعتمد على الوحدات البرمجيّة منخفضة المستوى بشكل مباشر هو أسلوب غير عمليّ ويؤدّي إلى مشاكل كبيرة عند إعادة استخدام الوحدات البرمجيّة عالية المستوى، تتمثّل هذه المشاكل في إجراء تعديلات برمجيّة عديدة عليها كي تتلاءم مع الاستخدام الجديد لها، وهذا بالطبع أمر غير جيّد. تُعتبر الوحدات البرمجيّة عالية المستوى بمثابة قلب التطبيق البرمجيّ. وقد نرغب في كثير من الأحيان أن نُعيد استخدامها في تطبيقات برمجيّة أخرى ولكن بدون إجراء تعديلات كبيرة عليها. يقترح روبرت مبدأ عكس التابعيّة والذي ينص على ما يلي: أ – لا ينبغي أن تعتمد الوحدات البرمجيّة عالية المستوى على الوحدات البرمجيّة منخفضة المستوى. يجب على كلّ منهما الاعتماد على واجهات (أصناف مجرّدة). ب – لا ينبغي أن تعتمد الواجهات/الأصناف المُجردّة على التفاصيل، فالتفاصيل هي من يجب أن تعتمد على الأصناف الواجهات. قد يكون من الصعب قليلًا فهم هذا المبدأ مباشرةً، لذلك اسمح لي بتوضيحه بشكل أفضل. يُقرّ هذا المبدأ أنّه ينبغي أن تكون هناك طبقة تجريديّة إضافيّة بين الوحدات البرمجيّة عالية ومنخفضة المستوى، تتألّف الطبقة التجريديّة من واجهات. فإذا كان لدينا وحدتان برمجيّتان أردنا أن تعتمد إحداهما على الأخر، فإنّ هذه الاعتماديّة ينبغي أن تتمّ عن طريق صنف واجهة معرّف خصيصًا لهذا الغرض. بهذا الأسلوب، فإنّ الوحدات البرمجيّة عالية المستوى لا تتعامل مباشرةً مع الوحدات البرمجيّة منخفضة المستوى. ستعمل الوحدات البرمجيّة منخفضة المستوى على تحقيق الواجهات (نستطيع القول أنّها سترث منها)، ففي حال أردنا استخدام أي وحدة برمجيّة في مشروع برمجيّ آخر فلن نحتاج إلى تعديل أيّ شيء ضمن الشيفرة البرمجيّة لها. فكل ما نحتاجه ببساطة هو تحقيق الواجهات التي ستعتمد عليها الوحدة البرمجيّة المراد إعادة استخدامها. بالنسبة للقسم الثاني من المبدأ (الفقرة ب) فهو ينبّه بأنّ الواجهات ينبغي ألّا تصمّم وفقًا للوحدات البرمجيّة منخفضة المستوى (التفاصيل). حيث ينبغي أن تُحقّق الأصناف الوجهات على نفس مستوى التجريد الذي تتمتّع به الوحدات البرمجيّة عالية المستوى. مثال عن عكس التابعيّة لنستعرض الآن مثالًا حول كيفية تطبيق هذا المبدأ. يدور هذا المثال حول التعامل مع الواجهات الرسوميّة للمستخدم، ليكن لدينا صنف يمثّل نافذة Window تحوي زرّين Button: class Button { public: void makeVisible(); }; class Window { Button* okButton; Button* cancelButton; Window() { okButton = new Button; okButton->makeVisible(); cancelButton = new Button; cancelButton->makeVisible(); } }; تكمن المشكلة هنا أنّه إذا تغيّر الصنف Button، سنضطّر إلى تغيير بانية الصنف Window أيضًا، وهذا بالطبع أمر غير مرغوب به، لأنّ الصنف Window سيكون عُرضةً للكثير من الاختبارات أثناء بناء البرنامج، وهذا سيؤدّي إلى الكثير من الأخطاء في كلّ مرّة نُعدّل فيها الصنف Button. يؤدّي استخدام صنف واجهة إلى تحسين التصميم إلى حدّ كبير: class IButton { public: static virtual IButton* getInstance() = 0; // factory method virtual void show() = 0; }; class Window { IButton* okButton; IButton* cancelButton; public: Window() { okButton = IButton::getInstance(); okButton->show(); cancelButton = IButton::getInstance(); cancelButton->show(); } }; class Button : public IButton { public: void show(); }; كما نرى الآن، يوجد صنف واجهة اسمه IButton وكل من الصنفين Button وWindow يعتمدان عليه. وهذا أمر جيّد للغاية، ففي حال أردنا استخدام الصنف Window في تطبيق برمجيّ جديد، فكل ما علينا هو استخدام أزرار Button تُحقّق الواجهة IButton فحسب. نلاحظ أيضًا التّابع الساكن getInstance الذي نستخدمه للحصول على الكائن الملائم من صنف الزر الذي يُحقّق صنف الواجهة IButton. المصادر http://www.objectmentor.com/publications/dip.pdf http://www.oodesign.com/dependency-inversion-principle.html http://en.wikipedia.org/wiki/Dependency_inversion_principle ترجمة -وبتصرّف- للمقال Dependency Inversion Principle لصاحبه Radek Pazdera.