اذهب إلى المحتوى

البحث في الموقع

المحتوى عن 'تابع'.

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المحتوى


التصنيفات

  • الإدارة والقيادة
  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • السلوك التنظيمي في المؤسسات
  • عالم الأعمال
  • التجارة والتجارة الإلكترونية
  • نصائح وإرشادات
  • مقالات ريادة أعمال عامة

التصنيفات

  • مقالات برمجة عامة
  • مقالات برمجة متقدمة
  • PHP
    • Laravel
    • ووردبريس
  • جافاسكربت
    • لغة TypeScript
    • Node.js
    • React
    • Vue.js
    • Angular
    • jQuery
    • Cordova
  • HTML
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • لغة C#‎
    • ‎.NET
    • منصة Xamarin
  • لغة C++‎
  • لغة C
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • لغة Rust
  • برمجة أندرويد
  • لغة R
  • الذكاء الاصطناعي
  • صناعة الألعاب
  • سير العمل
    • Git
  • الأنظمة والأنظمة المدمجة

التصنيفات

  • تصميم تجربة المستخدم UX
  • تصميم واجهة المستخدم UI
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب GIMP
    • كريتا Krita
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • مقالات DevOps عامة
  • خوادم
    • الويب HTTP
    • البريد الإلكتروني
    • قواعد البيانات
    • DNS
    • Samba
  • الحوسبة السحابية
    • Docker
  • إدارة الإعدادات والنشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
    • ريدهات (Red Hat)
  • خواديم ويندوز
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • شبكات
    • سيسكو (Cisco)

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح
  • مبادئ علم التسويق

التصنيفات

  • مقالات عمل حر عامة
  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • العمل الحر المهني
    • العمل بالترجمة
    • العمل كمساعد افتراضي
    • العمل بكتابة المحتوى

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
    • بريستاشوب
    • أوبن كارت
    • دروبال
  • الترجمة بمساعدة الحاسوب
    • omegaT
    • memoQ
    • Trados
    • Memsource
  • برامج تخطيط موارد المؤسسات ERP
    • تطبيقات أودو odoo
  • أنظمة تشغيل الحواسيب والهواتف
    • ويندوز
    • لينكس
  • مقالات عامة

التصنيفات

  • آخر التحديثات

أسئلة وأجوبة

  • الأقسام
    • أسئلة البرمجة
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات

التصنيفات

  • كتب ريادة الأعمال
  • كتب العمل الحر
  • كتب تسويق ومبيعات
  • كتب برمجة
  • كتب تصميم
  • كتب DevOps

ابحث في

ابحث عن


تاريخ الإنشاء

  • بداية

    نهاية


آخر تحديث

  • بداية

    نهاية


رشح النتائج حسب

تاريخ الانضمام

  • بداية

    نهاية


المجموعة


النبذة الشخصية

تم العثور على 5 نتائج

  1. تعرّفنا فيما سبق من دروس هذه السلسلة على أساسيات لغة بايثون، من مُتغيّرات وحلقات تكرار إلى الدوال، وقد حان الوقتُ للدخول إلى أساسيات البرمجة كائنية التوجّه Object Oriented Programming وهي ببساطة طريقة أخرى للبرمجة بحيث تكون أجزاء الشّيفرة مجموعة داخل دوال تُسمّى التوابع methods والدوال تكون داخل صنف معيّن Class. عند إنشاء كائن object من هذا الصنف فإنّنا نستطيع أن نُنفّذ عليه مُختلف العمليات الموجودة داخل التوابع والتي بدورها توجد داخل الصنف. هناك تسميّات عربية أخرى لهذا النّوع من البرمجة، لذا لا تقلق إذا صادَفتَ أحد هذه التّسميات في أماكن أخرى، فكلّها تُشير إلى نفس المعنى: برمجة غرضيّة التوجه برمجة شيئية المنحى برمجة كائنيّة المنحى بنية الصنف Class الصنف ببساطة يحتوي على أجزاء مُختلفة من الشيفرة تماما مثل الدالة، الفرق هنا هو أنّ الصنف يحتوي على دوال كذلك، وهذه الدوال تُسمى التّوابع، ويحتوي كذلك على مُتغيّرات وتنقسم هذه الأخيرة إلى نوعين، مُتغيّر الصنف، والمُتغيّر العادي، الفرق بينهما هو أنّك تستطيع الوصول إلى مُتغيّر الصنف في أي مكان داخل الصنف (سواء داخل التوابع أو خارجها). إنشاء صنف لإنشاء صنف في لغة بايثون كلّ ما عليك فعله هو كتابة كلمة class وبعدها اسم الصنف ثمّ إلحاق نقطتين، بعدها اكتب الشيفرة بإزاحة أربع مسافات: >>> class My_class: ... pass أنشأنا أعلاه صنفًا بسيطا باسم My_class وهو لا يفعل أي شيء يُذكر (كلمة pass تُخبر بايثون بالمرور دون تنفيذ أي شيء). إذا كتبت اسم الصنف على مفسّر بايثون فستجد مُخرجا كالتّالي: >>> My_class <class __main__.My_class at 0x7fd0efc41460> لاحظ بأنّ الكلمة الأولى من المُخرج هي class أي أنّنا أصبحنا نمتلك صنفًا جديدًا، ما يتبع at هو المكان في الذاكرة الذي وُضع فيه الصنف ويتغيّر بين الحين والآخر. إنشاء كائن من صنف بعد أن أنشأنا الصنف سنتمكّن الآن من إنشاء كائن من هذا الصنف، والكائن مُجرّد اسم تماما كالمُتغيّر: my_object = My_class() الآن الكائن my_object هو من صنف My_class. تعريف المتغيرات داخل صنف يُمكننا أن نُعرّف مُتغيّرات في الصنف تماما كما نُعرّف المُتغيّرات بشكل عادي. class My_class: my_variable = 'This is my variable' للوصول إلى المُتغيّر ننشئ أولا كائنا من الصنف وبعدها نكتب اسم الكائن ثمّ نقطة ثمّ اسم المُتغيّر: my_object = My_class() print my_object.my_variable المُخرج: This is my variable يُمكن كذلك الحصول على النّتيجة ذاتها في سطر واحد: print My_class().my_variable إنشاء التوابع التوابع هي دوال خاصّة بالصنف، ويُمكننا إنشاء التابع بنفس الطّريقة التي نُنشئ بها الدالة، الإختلاف هنا هو أنّ جميع التوابع يجب أن تُعرّف مع مُعامل باسم self وذلك للإشارة إلى أنّ الدالة/التابع تابع للصنف، لننشئ تابعا داخل صنف الآن. class My_class: my_variable = 'This is my variable' def my_method(self): print 'This is my method' الآن إذا أنشأنا كائنا فإنّنا سنتمكّن من الوصول إلى التابع، وتذكّر بأنّ التابع تلحقه الأقواس: my_object = My_class() my_object.my_method() المُخرج: This is my method يُمكن كذلك الحصول على النّتيجة ذاتها في سطر واحد: My_class().my_method() كما تُلاحظ فقد نُفّذت الشيفرة الموجودة داخل التّابع my_method ويُمكننا كذلك أن نجعل التّابع يقبل المُعاملات، لكن تذكّر الحفاظ على الكلمة self كمُتغيّر أول. class My_class: my_variable = 'This is my variable' def my_method(self, my_parameter): print 'This is my method ; {} is my parameter'.format(my_parameter) يُمكنك استدعاء التّابع كالتّالي: my_object = My_class() my_object.my_method('Parameter1') my_object.my_method('Parameter2') المُخرج: This is my method ; Parameter1 is my parameter This is my method ; Parameter2 is my parameter في البرنامج السّابق، أنشأنا أولا صنفًا باسم My_class وقُمنا بتعريف مُتغيّر، ثمّ بتعريف تابع باسم my_method يقبل مُعاملين self و my_parameter، بالنّسبة لاستدعاء التّابع، فنحتاج فقط إلى تمرير المُعاملات الموجودة بعد المُعامل selfولا نحتاج إلى تعيين قيمة لهذا المُعامل. مُلاحظة: يُمكنك إعادة تسميّة المُعامل الأول كما تشاء، أي أنّ البرنامج التّالي سيعمل دون مشاكل. class My_class: def my_method(this, my_parameter): print '{} is my parameter'.format(my_parameter) ولكن رغم ذلك فالمُتعارف عليه بين مُبرمجي لغة بايثون هو استعمال self، وفي كثير من اللغات الأخرى تُستعمل this عوضا عن self، أما في برامِجك فمن المُفضّل الإبقاء على هذه التّسميّة المُتعارف عنها، وذلك لتكون شيفراته سهلة القراءة. الوصول إلى متغيرات الصنف داخل التوابع تأمّل الصنف التّالي: class Person: lastname = 'Dyouri' job = 'Writer, Developer' def say_hello(self): name = 'Abdelhadi' print 'Hello, My name is {}'.format(name) البرنامج أعلاه بسيط جدا، أولا نعرّف صنف باسم Person وبعدها نقوم بتعيين قيمتين للمُتغيّرين name و lastname، وبعدها عرّفنا تابعا باسم say_hello يطبع جملة Hello, My name is Abdelhadi. كلّ شيء جيد، لكن ماذا لو أردنا أن نصل إلى المُتغيّرات الأخرى الموجودة خارج التّابع، فلا يُمكننا مثلا أن نقوم بالأمر كالتّالي: class Person: lastname = 'Dyouri' job = 'Writer, Developer' def say_hello(self): name = 'Abdelhadi' print 'Hello, My name is {}'.format(name) print lastname print job ستحصل على الخطأ التّالي: global name 'lastname' is not defined لتفادي هذا الخطأ سنستعمل كلمة self قبل المُتغيّر. class Person: lastname = 'Dyouri' job = 'Writer, Developer' def say_hello(self): name = 'Abdelhadi' print 'Hello, My name is {}'.format(name) print 'My Last name is {} '.format(self.lastname) print 'I am a {}'.format(self.job) استدعاء التّابع: me = Person() me.say_hello() المُخرج: Hello, My name is Abdelhadi My Last name is Dyouri I am a Writer, Developer لاحظ بأنّنا قُمنا بالوصول إلى مُتغيّر lastname عن طريق استدعائه بـ self.lastname وكذا الحال مع المُتغيّر job، وهذه الطّريقة مُشابهة لاستخدام كلمة global الفرق هنا أنّ هذه الأخيرة تُمكن من الوصول إلى المُتغيّر في كامل البرنامج، أمّا كلمة self فتُشير إلى المُتغيّر المُعرّف في الصنف الحاليّة فقط. لتفهم أكثر كيفيّة عمل الكلمة self فقط تخيّل بأنّها تحمل نفس اسم الصنف، مثلا: class Person: lastname = 'Dyouri' job = 'Writer, Developer' def say_hello(self): name = 'Abdelhadi' print 'Hello, My name is {}'.format(name) print 'My Last name is {} '.format(Abd.lastname) print 'I am a {}'.format(Abd.job) لاحظ بأنّنا غيّرنا كلمة self إلى اسم الصنف واستمرّ عمل البرنامج دون مشاكل. وبنفس الطّريقة يُمكنك أن تستدعي تابعا داخل تابع آخر في نفس الصنف: class Person: def say_name(self): print 'Abdelhadi' def say_hello(self): print 'Hello My name is:' self.say_name() المُخرج: Hello My name is: Abdelhadi ما حدث هو أنّ التّابع say_hello قام بطباعة جملة :Hello My name is ثمّ قام باستدعاء التّابع say_name الذي قام بدوره بطباعة الاسم Abdelhadi. لماذا تستعمل البرمجة الكائنية، ومتى يجب علي استخدامها قد تُلاحظ بأنّ ما يُمكنك فعله بالبرمجة الكائنيّة يُمكن القيام به بالدوال والمُتغيّرات فقط. هذا صحيح، وهو أمر واضح، البرمجة الكائنيّة تُستعمل أساسا إذا كان البرنامج الذي تبنيه مُعقّدا مع العديد من الوظائف المُتعلّقة ببعضها (كمكتبة برمجيّة)، مثلا لنقل بأنّك تُطوّر برنامجا مسؤولا عن جلب بيانات من موقع مُعيّن، وبعدها التّعديل عليها، ثمّ إخراج مستند PDF يحتوي على هذه البيانات بشكل يُسهّل قراءتها، هنا ستحتاج إلى صنف لجلب البيانات والتّعديل عليها، وصنف أخرى لتحويل البيانات إلى نصّ مقروء واضح ثمّ إلى ملفّ PDF. إذا نشرت برنامجك مع صديقك وأراد أن يعمل على الجزء الثاني لإضافة وظيفة تُمكن المُستخدم من طباعة المُستند فلا يُعقل أن يضطر للمرور على كل ما يتعلّق بجلب البيانات فقط لأنّه يريد أن يضيف خاصيّة لا علاقة لها بجلب البيانات. استعمال البرمجة الكائنيّة في هذا المشروع سيسمح لك بالتّركيز على الجزء الأول، وسيسمح لصديقك بالتّركيز على تطوير الجزء الثاني. خلاصة الأمر هي أنّك لست مضطرا لاستعمال البرمجة الكائنيّة إلا إذا كان برنامجك طويلا يحتوي على وظائف تتعلّق ببعضها البعض (وظائف من نفس الصنف)، ونسبة استخدام الآخرين لشيفرتك عالية. تمارين التمرين 1 أنشئ صنفًا باسمك، وقم بتعريف مُتغيّرين lastname (الاسم العائلي) و age (العمر)، ثم أنشئ كائنا باسم me (أنا) وقم بطباعة اسمك العائلي وعمرك. التمرين 2 أنشئ صنفًا باسم Car (سيارة) وقم بتعريف مُتغيّرات لصفات السّيارة، مثلا brand لاسم الشّركة، release_date لتاريخ الإعلان عن السّيارة. التمرين 3 أضف توابع إلى الصنف Car التي أنشأتها في التّمرين الثّاني، يُمكن أن تكون التوابع عبارة عن عمليّات تقوم بها السّيارة مثلا move للحركة، stop للتوقّف، slow_down لتخفيض السّرعة، وقم بطباعة جمل تفيد بأنّ العمليّة قد نجحت. المفروض أن يتمكّن الآخرون من إنشاء كائنات خاصّة بهم بحيث تُستخدم بهذه الطّريقة: bmw = Car() bmw.move() bmw.slow_down() bmw.stop() خاتمة تعرّفنا في هذا الدّرس على بعض من أهم أساسيات البرمجة الكائنيّة التوجه في لغة بايثون وهذا الموضوع أطول من أن أشرحه في درس واحد لذلك سيكون الدّرس التّالي تكملة لما تعلّمناه في هذا الدّرس حول تعلم بايثون وسيغطي مفاهيم أخرى حول البرمجة كائنية التوجّه.
  2. MySQL replication هي العمليّة التي يمكن من خلالها نسخ البيانات أوتوماتيكيًا من أحد مخدّمات قاعدة بيانات MySQL “الرئيسي” (master) إلى واحد أو أكثر من مخدّمات قواعد بيانات MySQL “التابع” (slaves). وعادةً ما تستخدم لتوزيع إمكانيّة وصول القراءة read access على مخدّمات متعددة من أجل قابلية التوسع scalability، كما يمكن أن تستخدم أيضًا لأغراض أخرى مثل تجاوز الفشل failover، أو تحليل البيانات على الـ slave من أجل عدم زيادة التحميل على الـ master. كما أنّ الـ master-slave replication هي عمليّة باتجاه واحد (من الـ master إلى slave)، تستخدم قاعدة بيانات الـ master فقط لعمليات الكتابة. بينما يمكن أن توزّع عمليات القراءة على عدّة قواعد بيانات slave. ما الذي يعنيه إذا استخدم master-slave replication كحل للتوسع، ستحتاج لأن تملك على الأقل مصدرين محدّدين للبيانات، واحد لعمليات الكتابة وآخر لعمليات القراءة. يعمل مطوّرو MySQL عادةً على جهاز واحد فقط و ويسعون لأن يكون لديهم كامل بيئة التطوير على ذلك الجهاز. مع منطق عدم الاعتماد على شبكة أو اتصال بالإنترنت. إذا كان هناك حاجة لـ master-slave replication فلأنه على سبيل المثال، يحتاجون إلى اختبار النسخ المتماثل/التكرار replication في بيئة التطوير قبل نشر التغييرات في مكان آخر، عليهم إنشاؤئه على نفس الجهاز. إن الإعداد لمثال MySQL واحد (single MySQL instance) بسيط نوعًا ما، ونحتاج لبذل بعض الجهد الإضافي لإعداد المثال الثاني، وبعدها عملية التكرار master-slave replication. للمتابعة في هذه الدرس خطوة بخطوة، اخترت Ubuntu Linux كنظام تشغيل مضيف (host). والأوامر الواردة هي من أجل هذا النظام. إذا أردت إعداد الـ MySQL master-slave replication الخاص بك على نظام تشغيل مختلف، ستكون بحاجة إلى القيام بتعديلات على هذه الأوامر. ومع ذلك ، المبادئ العامة لإعداد الـ MySQL master-slave replication على نفس الجهاز هي نفسها بالنسبة لجميع أنظمة التشغيل. تثبيت أول مثالMySQL (MySQL instance) إذا كان لديك مسبقًا مثال قاعدة بيانات MySQL واحد على جهازك، فيمكنك تجاوز هذه الخطوة. هذه أسهل طريقة لتثبيت MySQL على نظام Ubuntu وهي بتشغيل الأوامر التالية في موجّه الطرفية (terminal prompt): sudo apt-get install mysql-server خلال عملية التثبيت، ستُقاطع لوضع كلمة مرور لمستخدم root لـ MySQL. إعداد mysqld_multi من أجل إدارة مثالية لـ MuSQL على نفس الجهاز بكفاءة، نحن بحاجة إلى استخدام mysqld_multi. الخطوة الأولى في إعداد mysqld_multi هي إنشاء مجموعتي [mysqld] منفصلتين في الملف الموجود my.cnf. المكان الافتراضي لملف my.cnf في Ubuntu هو /etc/mysql/. لذلك افتح ملف my.cnf بمحرّر نصوصك المفضّل، وسمِّ مجموعة [mysqld] الموجودة إلى [mysqld1]. هذه المجموعة المسمّاة تستخدم لتكوين أول مثال MySQL وستكوّن أيضا كمثال رئيسي. كما هو الحال في MySQL master-slave replication كل مثال يجب أن يكون له server-id فريد خاص به، أضف السطر التالي في مجموعة [mysqld1]: server-id = 1 نظرًا لأننا بحاجة إلى مجموعة [mysqld]منفصلة لمثال MySQL الثاني ، انسخ المجموعة [mysqld1] مع كافة التهيئات الحالية، والصقها في ملف my.cnf نفسه. الآن، أعد تسمية المجموعة المنسوخة إلى [mysqld2]، وقم بإجراء التغييرات التالية في تكوين الـ slave: server-id = 2 port = 3307 socket = /var/run/mysqld/mysqld_slave.sock pid-file = /var/run/mysqld/mysqld_slave.pid datadir = /var/lib/mysql_slave log_error = /var/log/mysql_slave/error_slave.log relay-log = /var/log/mysql_slave/relay-bin relay-log-index = /var/log/mysql_slave/relay-bin.index master-info-file = /var/log/mysql_slave/master.info relay-log-info-file = /var/log/mysql_slave/relay-log.info read_only = 1 لإعداد مثيل MySQL الثاني كـتابع slave ، اضبط server-id إلى 2، والتي يجب أن تكون مختلفة بالنسبة لـ master’s server-id. كلا المثالين سيُشغّلان على نفس الجهاز، اضبط منفذ المثال الثاني إلى قيمة 3307 بحيث يمتلك رقم مختلف عن المنفذ الخاص بالمثال الأول، والذي يكون افتراضيًا 3306. من أجل تفعيل هذا المثال الثاني ليستخدم نفس MySQL binaries، نحتاج لضبط قيم مختلفة للـ socket، pid-file، datadir و log_error. نحن أيضًا بحاجة لتفعيل relay-log من أجل استخدام المثال الثاني كتابع (slave) (المتغيرات relay-log، relay-log-index و relay-log-info-file)، فضلًا عن تعيين master-info-file. أخيرًا، من أجل جعل المثال التابع للقراءة فقط read-only، ضبط المتغير read_only بقيمة 1. يجب أن تكون حذرًا معه فهو لا يمنع التغيرات بشكل كامل على الـ slave. حتى عندما تضبط read_only إلى 1، سيسمح للتحديثات فقط من المستخدمين الذين يملكون امتياز SUPER. أدخل MySQL المتغير الجديد super_read_only لمنع إجراء تغييرات من قبل مستخدمين الـ SUPER. هذا الخيار متوفر مع الإصدار 5.7.8. بعيدًا عن مجموعات الـ [mysqld1] و [mysqld2]، نحن بحاجة إلى إضافة مجموعة جديدة [mysqld_multi] إلى ملف my.cnf. [mysqld_multi] mysqld = /usr/bin/mysqld_safe mysqladmin = /usr/bin/mysqladmin user = multi_admin password = multipass بمجرد تثبيتنا لمثال MySQL الثاني، والقيام بتشغيلهما، سنمنح الامتيازات المناسبة للمستخدم multi_admin ليكون قادرًا على إيقاف تشغيل أمثلة MySQL. أنشئ مجلدات جديدة من أجل مثال MySQL الثاني في الخطوة السابقة قمنا بإعداد ملف التكوين من أجل مثال MySQL الثاني. في ملف التكوين هذا يتم استخدام مجلدين جديدين. يجب استخدام أوامر لينكس التالية من أجل إنشاء هذه المجلدات مع الامتيازات المناسبة: mkdir -p /var/lib/mysql_slave chmod --reference /var/lib/mysql /var/lib/mysql_slave chown --reference /var/lib/mysql /var/lib/mysql_slave mkdir -p /var/log/mysql_slave chmod --reference /var/log/mysql /var/log/mysql_slave chown --reference /var/log/mysql /var/log/mysql_slave إعدادات أمنية إضافية في AppArmor في بعض بيئات لينكس، هناك حاجة إلى إعدادات أمن AppArmor لتشغيل مثال MySQL الثاني. على الأقل هي مطلوبة في Ubuntu . لإعداد AppArmor بشكل صحيح. حرّر ملف /etc/apparmor.d/usr.sbin.mysqld بمحرّر نصوصك المفضّل، وأضف الأسطر التالية: /var/lib/mysql_slave/ r، /var/lib/mysql_slave/** rwk، /var/log/mysql_slave/ r، /var/log/mysql_slave/* rw، /var/run/mysqld/mysqld_slave.pid rw، /var/run/mysqld/mysqld_slave.sock w، /run/mysqld/mysqld_slave.pid rw، /run/mysqld/mysqld_slave.sock w، بعد أن تحفظ الملف، أعد تشغيل الجهاز حتى تصبح هذه التغييرات نافذة المفعول. تثبيت مثال MySQL الثاني يمكن اتباع عدّة نُهج مختلفة لتركيب مثال MySQL الثاني. يستخدم النهج المعروض في هذه الدورة التعليميّة نفس ثنائيات الـ MySQL كما في الأول، مع ملفات بيانات منفصلة ضرورية للتثبيت الثاني. حيث أننا قمنا بالفعل بإعداد ملف التكوين والمجلدات الضرورية والتغييرات الأمنية في الخطوات السابقة، الخطوة الأخيرة في التثبيت للمثال الثاني لـ MySQL هي تهيئة دليل بيانات MySQL. نفذ الأمر التالي من أجل تهيئة دليل بيانات MySQL جديد: mysql_install_db --user=mysql --datadir=/var/lib/mysql_slave بمجرد تهيئة دليل بيانات MySQL، يمكنك بدء كل من مثالي MySQL باستخدام الخدمة mysqld_multi. mysqld_multi start ضع كلمة سر الـ root لمثال MySQL الثاني باستخدام الـ mysqladmin مع المضيف والمنفذ المناسبين. وضع في اعتبارك ، أنه إذا تَركت المنفذ والمضيف دون تحديد، سيتصل mysqladmin بأول مثال MySQL افتراضيًا. mysqladmin --host=127.0.0.1 --port=3307 -u root password rootpwd في المثال الذي في الأعلى قم بوضع “rootpwd” ككلمة سر، ولكن يستحسن استخدام كلمة سر أكثر أمنًا. تهيئة إضافية لـ mysqld_multi في نهاية قسم " إعداد mysqld_multi، كتبت أننا سنقدم امتيازات مناسبة للمستخدم multi_admin في وقت لاحق، والآن حان الوقت لذلك. نحن بحاجة إلى منح امتيازات هذا المستخدم في كلا المثالين، لذلك دعونا أولًا نقوم بالاتصال بالمثال الأول: mysql --host=127.0.0.1 --port=3306 -uroot -p عند تسجيلك الدخول، نفّذ الأمرين التاليين: mysql> GRANT SHUTDOWN ON *.* TO 'multi_admin'@'localhost' IDENTIFIED BY 'multipass'; mysql> FLUSH PRIVILEGES; اخرج من MySQL client، وقم بالاتصال بالمثال الثاني: mysql --host=127.0.0.1 --port=3307 -uroot -p عند تسجيلك الدخول، نفّذ نفس الأمرين كما في الأعلى: mysql> GRANT SHUTDOWN ON *.* TO 'multi_admin'@'localhost' IDENTIFIED BY 'multipass'; mysql> FLUSH PRIVILEGES; اخرج من MySQL client. بدء كل من مثالي MySQL أوتوماتيكيًا عند الإقلاع الخطوة الأخيرة في إعداد mysqld_multi هي التثبيت لسكريبت الإقلاع الأتوماتيكي في الـ init.d. لفعل ذلك، أنشئ ملف جديد سمّه mysqld_multi في /etc/init.d، وامنحه الامتيازات المناسبة: cd /etc/init.d touch mysqld_multi chmod +x /etc/init.d/mysqld_multi افتح هذا الملف الجديد بمحرّر نصوصك المفضل، وانسخ السكريبت التالي: #!/bin/sh ### BEGIN INIT INFO # Provides: scriptname # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start daemon at boot time # Description: Enable service provided by daemon. ### END INIT INFO bindir=/usr/bin if test -x $bindir/mysqld_multi then mysqld_multi="$bindir/mysqld_multi"; else echo "Can't execute $bindir/mysqld_multi"; exit; fi case "$1" in 'start' ) "$mysqld_multi" start $2 ;; 'stop' ) "$mysqld_multi" stop $2 ;; 'report' ) "$mysqld_multi" report $2 ;; 'restart' ) "$mysqld_multi" stop $2 "$mysqld_multi" start $2 ;; *) echo "Usage: $0 {start|stop|report|restart}" >&2 ;; esac أضف خدمة mysqld_multi لـ runlevels الافتراضي بالأمر التالي: update-rc.d mysqld_multi defaults أعد تشغيل جهازك، وتحقق من أن كلا مثالي MySQL قيد التشغيل باستخدام الأمر التالي: mysqld_multi report إعداد Setup master-slave replication الآن، عندما يكون لدينا مثالي MySQL قيد التشغيل على نفس الجهاز، نقوم بإعداد المثال الأول كـ master، والثاني كـ slave. تم القيام بجزء واحد من التكوين configuration مسبقا في فصل “إعداد mysqld_multi”. التغيير الوحيد المتبقي في الملف my.cnf هو ضبط binary logging على الـ master. لفعل ذلك، حرّر ملف my.cnf مع التغيرات التالية والإضافات في المجموعة [mysqld1]: log_bin = /var/log/mysql/mysql-bin.log innodb_flush_log_at_trx_commit = 1 sync_binlog = 1 binlog-format = ROW أعد تشغيل مثال MySQL الرئيسي (master MySQL instance) لتأخذ التغيرات مفعولها: mysqld_multi stop 1 mysqld_multi start 1 من أجل اتصال الـ slave بالـ master بامتيازات تكرار replication مناسبة، يجب أن ينشأ المستخدم الجديد في الـ Master. اتصل بمثال maste باستخدام الـ MySQL clien مع المضيف والمنفذ المناسبين: mysql -uroot -p --host=127.0.0.1 --port=3306 أنشئ مستخدم جديد من أجل التكرار replication: mysql> CREATE USER 'replication'@'%' IDENTIFIED BY 'replication'; mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication'@'%'; اخرج من MySQL client. نفّذ الأمر التالي من أجل إنشاء ملف نسخ احتياطي (dump) لبيانات الـ master: mysqldump -uroot -p --host=127.0.0.1 --port=3306 --all-databases --master-data=2 > replicationdump.sql هنا استخدمنا الخيار --master-data=2 من أجل الحصول على تعليق يحتوي على عبارة CHANGE MASTER داخل ملف النسخ الاحتياطي، ذاك التعليق يشير الى إحداثيات الـ replication في وقت النسخ الاحتياطي، وسنحتاج هذه الإحداثيات لاحقًا لتحديث معلومات الـ master في مثال الـ slave. وهنا مثال لهذا التعليق: -- -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001'، MASTER_LOG_POS=349; استورد dump الذي أنشأته في الخطوة السابقة ضمن مثال الـ slave. mysql -uroot -p --host=127.0.0.1 --port=3307 < replicationdump.sql أخيرًا، من أجل اتصال مثال الـ slave بمثال الـ master، يجب تحديث معلومات الـ master في الـ slave مع متغيرات الاتصال المناسبة. اتصل بمثال الـ slave باستخدام MySQL clien مع المضيف والمنفذ المناسبين: mysql -uroot -p --host=127.0.0.1 --port=3307 نفّذ الأمر التالي لتحديث معلومات الـ master (خُذ احداثيات التكرار replication من ملف (dump) replicationdump.sql، كما شُرح سابقًا): mysql> CHANGE MASTER TO -> MASTER_HOST='127.0.0.1'، -> MASTER_USER='replication'، -> MASTER_PASSWORD='replication'، -> MASTER_LOG_FILE='mysql-bin.000001'، -> MASTER_LOG_POS=349; نفذ الأمر التالي من أجل تشغيل الـ slave: mysql> START SLAVE; نفذ الأمر التالي للتأكد من أن replication قيد التشغيل: mysql> SHOW SLAVE STATUS \G تهانينا. تم إعداد MySQL master-slave replication على نفس الجهاز لديك بنجاح. خاتمة وجود النسخ المتماثل master-slave مهيئًا في بيئة التطوير الخاصة بك مفيد إذا كنت بحاجة لحل للتوسع في بيئة الإنتاج. بهذه الطريقة، سيكون لديك مصادر بيانات منفصلة مُهيئة لعمليات الكتابة والقراءة وبذلك تكون قادرًا على اختبار أن كل شيء يعمل محلياً كما هو متوقع قبل النشر. بالإضافة إلى ذلك، قد تحتاج إلى تكوينات أمثلة slave على نفس الجهاز لاختبار موازن الحمل الذي يوزّع عمليات القراءة إلى عدد من الـ slave. في هذه الحالة، يمكنك استخدام هذه الطريقة لإعداد أمثلة أخرى بتكرار كل الخطوات السابقة نفسها. ترجمة -وبتصرّف- للمقال MySQL Master-Slave Replication on the Same Machine لصاحبه Ivan Bojovic
  3. ما الذي تعنيه كلمة "مجال" برأيك؟ قد تبدو من اسمها بأنّها تشير إلى جزءٍ من شيفرة التّطبيق، ربّما تم عملها لنتجنّب استخدام المجال العام الذي يسبّب العديد من المشاكل. يبدو أنّ الأمر بسيط، وإنّه لمن الحكمة أن يقوم إطار العمل بتطبيق شيءٍ كهذا، ربّما ليس علينا التّفكير في أمر المجالات أكثر من ذلك، هل يمكننا الانتقال للفصل التالي؟ ليس بهذه السّرعة، لن يكون هذا الفصل طويلًا ولكنه سيغطي أمرين شديدي الأهمّيّة: وراثة المجالات، وهرميّة المجالات، فقد يحوي تطبيق Angular نموذجيًّا على العشرات، المئات وربّما الآلاف من المجالات. قبل أن نبدأ، لنقم بإعداد البيئة لتُلائم أمثلة هذا الفصل. التهيئةفي فصل المبادئ، تعلّمنا كيف نقوم بإضافة التّوجيه ng-app إلى العنصر الذي نرغب بأن تقوم Angular بمعالجته. <body ng-app="app"> <!-- الأمثلة هنا --> </body>الوسيط الذي نمرره إلى التّوجيه ng-app هو اسم الوحدة التي تشكل جذر التطبيق الحالي (في المثال قمنا باستخدام الاسم app على سبيل الاصطلاح). سنقوم بتغطية الوحدات بعمق في فصل لاحق. أما الآن فاعتبر السّطور التّالية مجرّد شيفرات اصطلاحية يمكنك نسخها دون فهم محتواها. angular.module('app', []); angular.module('app').config(['$controllerProvider', function($controllerProvider) { $controllerProvider.allowGlobals(); }]);والآن بعد كتابة تلك الشّيفرات الخارجة عن الدّرس، يمكننا الدخول في الموضوع. scope$في الفصل الماضي، المتحكمات، تعلّمنا كيفيّة تحضير النّموذج عن طريق ربط العناصر (الخصائص properties) إلى المرجع scope$. لنقم بتكرار التمرين ثانيةّ. function NameController($scope) { $scope.name = "First"; }باستخدام التّوجيه ng-controller يمكننا استدعاء تابع التّحكم المكتوب أعلاه، وذلك ضمن سياق أحد عناصر المستند، وعندها ستكون أيّ بيانات قمنا بإسنادها للمجال متاحةً للاستخدام داخل العنصر. <p ng-controller="NameController"> {{name}} </p>الناتج Firstعناصر المستند التي تقع خارج العنصر الذي قمنا باستدعاء المتحكّم NameController فيه، لن تكون قادرةً على الوصول إلى العناصر المرتبطة بالمتحكّم، لنجرّب ذلك. <div> <p> Outside the scope: {{name}} </p> <div ng-controller="NameController"> <p> Inside the scope: {{name}} </p> </div> </div>الناتج Outside the scope: Inside the scope: Firstوهذا المثال يوضّح ارتباط عمل المتحكّم والمجال معًا، والآن لننظر إلى الحالة المعاكسة، تطبيق Angular بمجال واحد. rootScope$تحاول Angular جاهدةً أن تتأكد من ابتعادنا عن المشاكل أثناء استخدام المجالات، لذا تقوم بإنشاء مجالٍ جديد لكلّ متحكّم. يتمّ بناء المجالات وفق بنيةٍ هرميّة، ويتربّع في جذر هرم المجالات في كلّ تطبيقات Angular مجالٌ أبٌ وحيدٌ لجميع المجالات، يمكننا الوصول إلى هذا الجذر باستخدام الوسيط ذو الاسم المخصص rootScope$ داخل المتحكّم، واستخدامه بدلًا من المرجع المعتاد (والمستحسن) scope$. function RootNameController($rootScope) { $rootScope.name = "First"; }الشّيفرة واضحة وليس فيها صعوبة، وهي تعمل بشكل طبيعي. <p ng-controller="RootNameController"> {{name}} </p>الناتج Firstولكنّ المشاكل تبدأ بالظّهور عندما نحاول الوصول إلى عنصر له الاسم نفسه من متحكّم آخر. function SecondRootNameController($rootScope) { $rootScope.name = "Second"; }هذا لا يبشّر بالخير، فالمرجع rootScope$ وحيد (singleton) داخل التّطبيق، ولا يمكن أن يكون هناك سوى عنصر واحد له الاسم name. <p ng-controller="RootNameController"> {{name}} </p> <p ng-controller="SecondRootNameController"> {{name}} </p>الناتج Second Secondمن الواضح أنّ المتحكّم SecondRootNameController قد استبدل القيمة التي أسندها RootNameController للعنصر name. حسنًا، هذه هي مشكلة المتغيرات العامة، أليس كذلك؟ العزلتقدم Angular لنا بيئة آمنة عن طريق إنشاء مجالٍ خاصّ بكلّ متحكّم، لنقم بإعادة كتابة المتحكّمات السّابقة لتقوم بتهيئة النّموذج تهيئةً صحيحة، باستخدام المرجع scope$ بدلًا من rootScope$، وحاول مقارنة ذلك مع المثال السّابق الذي استخدمنا فيه rootScope$ لتعرف سبب إنشاء مجال لكلّ متحكّم، سنستخدم المتحكّمين التاليين: function SecondNameController($scope) { $scope.name = "Second"; }<p ng-controller="NameController"> {{name}} </p> <p ng-controller="SecondNameController"> {{name}} </p>الناتج First Secondأظهر المثال المخرجات الصحيحة، القيمة الصحيحة للعنصر name لكلا المتحكّمين. هذا العزل هو النّتيجة التي نحصل عليها عندما لا يكون أيٌّ من المتحكّمين ابنًا للآخر، أيّ أننا لم نقم بتعريف أحد المتحكّمين داخل عنصر في المستند محتوًى داخل متحكّمٍ آخر. ما الذي سيحدث لو قمنا بجعلهم متداخلين بدلًا من ذلك؟ المجالات المتداخلةبتعديلٍ صغيرٍ على المثال السابق، سنقوم بتحريك SecondNameController إلى عنصرٍ ابن للعنصر div الذي يقوم بتحميل المتحكّم NameController، وهذه الحالة هي ما يسمّى بالمجالات المتداخلة (nested). <div ng-controller="NameController"> <p> {{name}} </p> <p ng-controller="SecondNameController"> {{name}} </p> </div>الناتج First Secondالأمور تسير على ما يُرام، ولا يزال العنصر name معزولًا في كلا المجالين، ماذا لو قمتَ بعكس ترتيب العنصرين p في المثال السابق؟ هيا قم بتجربة ذلك، يُفترض بأنك سترى أنّ العنصرين name قد انعكس ترتيبهما. في الحقيقة، لا يعني ذلك بأنّ المجالين معزولين، فـAngular تقوم بتنظيم المتحكّمات في بنية هرميّة بالاعتماد على موضع المتحكّم في بنية المستند، والمتحكّم الابن يرث عناصر وخصائص أبيه. يرجع السبب في عدم حدوث تغيير في قيمة العنصر name في المثال السابق، إلى خاصّيّة التظليل، حيث يقوم العنصر name في الابن بتظليل قيمة العنصر name في الأب. لنجرّب الحصول على دليلٍ على هذا السلوك عن طريق تغيير اسم العنصر في المتحكّم الابن. function ChildController($scope) { $scope.childName = "Child"; }سنحاول إخراج قيمتي العنصرين في كلا المجالين، الأب والابن. <div ng-controller="NameController"> <p> {{name}} and {{childName}} </p> <p ng-controller="ChildController"> {{name}} and {{childName}} </p> </div>الناتج First and First and Childمن الواضح أنّ المتحكّم الأب NameController لا يملك صلاحيّةً للوصول إلى عناصر المتحكّم الابن، بينما يمكن للمتحكّم الابن ChildController أن يصل إلى عناصره وعناصر أبيه. بما أنّ العنصر name هو عنصر موروث من الأب، لا بدّ من أنّ التغيير على قيمته في مجال المتحكّم الابن سيؤدّي إلى تغيير قيمته في مجال الأب. سنضيف خانة إدخال ونربطها بالعنصر name. <div ng-controller="NameController"> <p> {{name}} </p> <p ng-controller="ChildController"> {{name}} </p> <input type='text' ng-model='name'> </div>إذا حاولت تعديل قيمة العنصر name في المثال السابق، ستجد أنّه يعمل كما هو متوقّع، فقيمة العنصر name تتغيّر في كلا المجالين، ولكن لاحظ بأنّنا نقوم بالتّغيير ضمن مجال الأب فقط. الوراثةقد ترغب أيضًا بتغيير قيمة العنصر name أيضًا في مجال الابن، ربّما تظنّ بأنّ هذا التغيير يجب أن ينعكس أيضًا على المتغير name في مجال الأب، لنجرّب ذلك، سنقوم بإضافة خانة إدخال لتسمح لنا بتعديل العنصر name في مجال الابن أيضًا. في العرض الخاصّ بالمثال، قم بالخطوات التالية بنفس الترتيب الذي سأذكره لك:أوّلًا، غيّر القيمة في خانة الإدخال العليا، ستلاحظ أنّ جميع القيم المرتبطة بالعنصر name قد تمّ تحديثها.ثانيًا، غيّر القيمة في خانة الإدخال السّفلى. <div ng-controller="NameController"> <p> name: {{name}} <br> <input type='text' ng-model='name'> </p> <p ng-controller="ChildController"> name: {{name}} <br> <input type='text' ng-model='name'> </p> </div>هل فاجَأَتك النّتيجة؟ تستخدم Angular طريقة JavaScript في وراثة الهيكل الخارجي (prototypal inheritance) هذا جيّدٌ إن كنت متمرّسًا فيها، فليس عليك تعلّم أيّ شيءٍ جديدٍ هنا، ولكنّه سيّءٌ لمن لم يواجه هذا النّوع من الوراثة من قبل، ففهمه ليس أمرًا بديهيًّا. تقول القاعدة: “إنّ تغيير قيمة عنصر ما في كائن في JavaScript، يؤدّي إلى إنشاء هذا العنصر في الكائن”، وهذه القاعدة البسيطة تشكّل مشكلةً أثناء التّعامل مع العناصر الموروثة التي تكون مظلّلة بالعنصر الخاص بالكائن الابن. حدث الأمر كالتّالي: في البداية لم يكن هناك أيّ عنصر اسمه name داخل الابن، ولكن عندما قمنا بتعديل النّصّ في خانة الإدخال السّفلى قامت Angular بإسناد النّص إلى العنصر name في الابن حيث تمّ إنشاء هذا العنصر في الابن، وعند حدوث ذلك، قام هذا العنصر بتظليل العنصر name في الأب، ومن ثمّ لم يعُد بإمكاننا الوصول إليه من الابن. كيف يمكننا التّعامل مع هذا الأمر في Angular، بحيث نتمكّن من تعديل بيانات النّموذج في مجالٍ موروث؟ لن يكون ذلك صعبًا، سيكون علينا فقط نقل العنصر name إلى داخل كائنٍ آخر. function InfoController($scope) { $scope.info = {name: "First"}; }function ChildInfoController($scope) { $scope.info.childName = "Child"; }<div ng-controller="InfoController"> <p> {{info.name}} and {{info.childName}} <br> <input type='text' ng-model='info.name'> </p> <p ng-controller="ChildInfoController"> {{info.name}} and {{info.childName}} <br> <input type='text' ng-model='info.name'> </p> </div>لاحظ أن ChildInfoController يعتمد على أبيه في إنشاء الكائن info، ما الذي سيحدث لو قمنا بتعديل شيفرة المتحكّم ChildInfoController واستبدلنا جسم التابع بالعبارة: scope.info = {childName: "Second$"};جرّب ذلك، سترى بأننا عدنا إلى إنشاء عنصرٍ جديد في الابن، مع تأثير التظليل الذي رأيناه سابقًا. scope.$watchتتعامل Angular أثناء عمليات الربط ثنائيّ الاتجاه مع العناصر في المجال بالطريقة التالية: عندما تستخدم خانة الدّخل المرتبطة للقيام بأيّ تغيير، يتمّ تحديث واجهة المستخدم في كلّ مكان، وهذا يختلف عن “الخصائص المحسوبة”(computed properties) وهي البيانات المأخوذة من مجال بيانات آخر. في المثال التالي، العنصر sum هو خصيصة محسوبة. function SumController($scope) { $scope.values = [1,2]; $scope.newValue = 1; $scope.add = function() { $scope.values.push(parseInt($scope.newValue)); }; // Broken -- doesn't trigger UI update $scope.sum = $scope.values.reduce(function(a, b) { return a + b; }); }يتم حساب قيمة العنصر sum فعليًّا عن طريق عملية بسيطة تستخدم التابع reduce في العبارة الأخيرة في المتحكّم SumController. في القالب الخاص بهذا المثال، سنستخدم أداة الدّخل select للسّماح للمستخدم باختيار الرّقم (2،1 أو 3) لإضافته إلى نهاية المصفوفة values.(كنقطة جانبيّة: لاحظ أنّ المتحكّم يعطي قيمةً ابتدائيّة للمتغيّر newValue, ولو لم نقم بذلك لكانت Angular ستضيف الاختيار الفارغ للقائمة في العنصر select، وذلك لتجنّب القيمة العشوائيّة التي يخزّنها newValue للخيار الأوّل المولّد عن طريق التّوجيه ng-options. هذا السلوك لا علاقة له بالمجالات ولكنّ العلم به أمرٌ مفيد.) <p ng-controller="SumController"> <select ng-model="newValue" ng-options="n for n in [1,2,3]"></select> <input type="button" value="Add" ng-click="add()"> The sum of {{values}} is {{sum}}. </p>عند النقر على Add ستتغيّر القيمة المعروضة لـsum، ولكن للأسف، الشّيفرة الخاصة بالمتحكّم تحتوي على أخطاء، ولن يعمل المتحكّم كما توقّعنا. لنقم الآن بتصحيح الخطأ، وذلك بنقل العبارة التي تقوم بالحساب الحقيقي للقيمة sum إلى تابع استدعاءٍ خلفيّ (callback). وعندما سنمرر هذا التابع كوسيط إلى scope.$watch$ مع وسيط آخر يمثّل عبارة المتابعة (في هذه الحالة هو اسم العنصر الذي يتم حساب sum منه)، سيؤدّي ذلك إلى جعل sum يتمّ إعادة حسابها كلّما تغيّر values. function SumController($scope) { $scope.values = [1,2]; $scope.newValue = 1; $scope.add = function() { $scope.values.push(parseInt($scope.newValue)); }; $scope.$watch('values', function () { $scope.sum = $scope.values.reduce(function(a, b) { return a + b; }); }, true); }والآن ستتغيّر قيمة العنصر sum ديناميكيًّا عند إضافة العناصر للمصفوفة. scope.$applyجميع التّوجيهات المدمجة في Angular والخاصة بعمليّة الربط ثنائيّ الاتجاه كاملة المزايا، ولكنّك قد تجد من فترة إلى أخرى سلوكًا تحتاج إلى إضافته. مثلًا، ماذا لو أردنا أن يقوم المستخدم بمسح الحالتين الحالة الحاليّة لخانة الدخل النّصّيّة و الحالة المرتبطة بها وذلك عندما يضغط زرّ esc؟ كيف يمكننا كتابة شيفرة التّعامل مع هذا الحدث؟ <div ng-controller="EscapeController"> <input type="text" ng-model="message"> is bound to "<strong ng-bind="message"></strong>". Press <code>esc</code> to clear it! </div>يجب علينا أوّلًا أن نصرّح عن المتغيّر ذو الاسم المخصّص element$ وتمريره كوسيط للمتحكّم، وذلك للسّماح لـAngular بحقن مرجعٍ في العنصر المرتبط بالمتحكّم. يمكننا استخدام التابع bind لتسجيل استدعاء خلفيّ لحدث keyup الذي يختبر ضغط الزّرّ esc، وداخل تابع الاستدعاء الخلفيّ هذا، سنقوم بتحديث عنصر المجال. قم بتجربة المثال التالي، اكتب شيئًا ثم اضغط esc. function EscapeController($scope, $element) { $scope.message = ''; $element.bind('keyup', function (event) { if (event.keyCode === 27) { // esc key // Broken -- doesn't trigger UI update $scope.message = ''; } }); }ليس بعد، بما أنّنا نتعامل مباشرةً (تقريبًا) مع عناصر المستند، سنحتاج إلى إخبار Angular عندما نريد أن تقوم بإعادة رسم العرض. نقوم بذلك عن طريق تغليف التّغييرات التي نقوم بها بتابع استدعاءٍ خلفيّ نمرّره إلى scope.$apply$. function EscapeController($scope, $element) { $scope.message = ''; $element.bind('keyup', function (event) { if (event.keyCode === 27) { // esc key $scope.$apply(function() { $scope.message = ''; }); } }); }جرّبها الآن، بعد أن أخبرنا Angular بما نريد، سيعمل كلّ شيء كما يجب. خلاصةإن حاولت تطبيق مفاهيم نموذج-عرض-متحكم (Model-view-controller (MVC على Angular، ستكون المجالات لغزًا بالنّسبة لك، قد تظنّ بأنّ الأمر بسيط، وأنّ المجالات هي جزءٌ من طبقة النّموذج، ولكن في Angular لا يكون الكائن نموذجًا حتّى يكون قابلًا للوصول إليه كعنصرٍ في المجال. ولكنّ القصّة تصبح أكثر إثارةً عندما ترى طريقة ارتباط المجالات بالمستند عن طريق المتحكّمات والتّوجيهات. بوضع سؤالنا الأكاديميّ جانبًا، فإن المجالات بديهيّةٌ وسهلة الاستخدام كما بيّنت أمثلة هذا الفصل. ترجمة وبتصرّف للفصل الرابع من كتاب: Angular Basics لصاحبه: Chris Smith.
  4. طلبت منك في الفصل السابق (المبادئ) أن تكبح جماح JavaScript بداخلك ريثما نستكشف القيمة الحقيقيةّ التي تقدّمها Angular، وهي تقديم امتدادات قويّة لـHTML لمطوّر النّهاية الأمامية front-end. لا تنتهي قصّة Angular هنا بالطّبع، والمنهج في مشاريع Angular هو تخصيص السّلوكيات عن طريق JavaScript، فإذا كنت تتحرّق شوقًا في الفصل الأوّل للبدء بكتابة شيفرات حقيقيّة فقد حان الوقت لذلك، إنه وقت كتابة شيفرات JavaScript. أكثر الطرق شيوعًا لتعديل العرض في Angular باستخدام JavaScript هي عن طريق استخدام متحّكم، وأبسط طريقة لكتابة متحكّم هي باستخدام تابع بناء (constructor) بسيط. لنبدأ بمثالٍ بسيط لنفهم تمامًا ما الذي يحدث، المثال التّالي لا يقوم بأي شيء، ولا يطبع "!Hello World" حتّى. ها هو متحكّمنا البسيط. function EmptyController() { };سنحتاج إلى تضمين مكتبة Angular ضمن الصفحة لتتم معالجة خصائص المجال التي تم تحضيرها عن طريق المتحكّم، ولذا يجب نسخ الشّيفرة التّالية ولصقها داخل العنصر head في كلّ الأمثلة. <html> <head> <script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.4.2/angular.js"></script> </head> <body ng-app="app"> <!-- كل الأمثلة توضع هنا --> </body> </html>يجب علينا ضبط إعدادات تطبيق Angular داخل مستند HTML ليقوم بتحميل الوحدة app، فقد تعرفّنا في الوحدة الأولى المبادئ على التّوجيه ng-app الذي نضيفه لأيّ عنصر في المستند لتقوم Angular بمعالجة ما بداخله، انظر الآن إلى استخدام ng-app في المثال التّالي، هل يمكنك الانتباه إلى الإضافة الجديدة؟ <body ng-app="app"> </body>يُمكن تعريف المتحكّمات كتوابع بناء معرّفة في المجال العام (global scope)، وهذه هي الطّريقة التي سنستخدمها في أمثلتنا في هذا الفصل. كان الشكل البسيط للمتحكّمات مدعومًا في Angular حتى النسخة 1.3 لتسهيل انطلاق المطوّرين مع المكتبة، ولكنّ ذلك يتطلب الآن إنشاء وتسمية وحدة للتطبيق. سنناقش تفاصيل استخدام angular.module في الفصول القادمة الوحدات، حقن التابعة، والخدمات. يمكنك التعامل مع المثال التّالي على أنّه شيفرة معياريّة مطلوبة: angular.module('app', []); angular.module('app').config(['$controllerProvider', function($controllerProvider) { $controllerProvider.allowGlobals(); }]);والآن بعد كتابة هذه الشّيفرة الخارجة عن سياق الحديث، لنعد إلى متحكّمنا عديم الفائدة. ng-controllerكالعادة، الطّريقة التي سنتّبعها للقيام بأيّ شيء، هي استخدام الموجّهات، سنستخدم الموجه ng-controller الذي يقوم بالعثور على التّابع الذي يتمّ تمرير اسمه إليه ثم استدعائه. <p ng-controller="EmptyController"> </p>وكما توقّعتَ، لن يقوم هذا التّابع بأيّ شيء، والآن إذًا ما هي هذه المتحكّمات وكيف نستخدمها؟ بناء النموذجينصّ المرجع الرسمي في النظرة العامة للمفهوم على أنّ وظيفة المتحكّم هي "الكشف عن المتغيرات والوظائفيّة للعبارات والتّوجيهات" وتشير كلمة "الوظائفية" إلى توابع الاستدعاء الخلفي (callback)، وسنتطرق إليها قريبًا، أمّا الآن فسنتكلّم عن تهيئة "المتغيّرات"، أو بعبارة أخرى تحضير النّموذج. أرجو منك أن تبقي في ذهنك أنّ وحدة Angular ليست سوى JavaScript عاديّة يمكن الوصول إليها ضمن مجال عبارة ما، وبذلك سيكون تحضير النّموذج أمرًا سهلًا للغاية. سنتمكّن من كتابة JavaScript عاديّة دون أيّ قيود، لنقم بإضافة عنصر إلى المتحكّم الفارغ، وليكن هذا العنصر سلسلة نصّيّة. function MessageController() { this.message = "This is a model."; }أمرٌ بسيط، أليس كذلك؟ هل قمنا الآن بإنشاء وحدة؟ ماذا تتوقّع؟ الإجابة هي "تقريبًا"، فعندما يكون بإمكاننا الوصول إلى العنصر message ضمن مجال العرض، ستكون هذه وحدةً بالفعل. أحد طرق القيام بذلك هي الكشف عن كامل المتحكّم كعنصرٍ بداخل المجال، ولن يكون هذا صعبًا كما تظنّ، كلّ ما عليك معرفته هو التركيب النحويّ المناسب للقيام بذلك. Controller as propertyNameيشرح توثيق المكتبة بالنّسبة للتّوجيه ng-controller بأنه يمكنك تمرير عبارة Controller as propertyName كوسيط للتّوجيه ng-controller، وهذه الميزة متاحة في النسخة 1.2 فما فوق. <p ng-controller="MessageController as controller"> {{controller.message}} </p>الناتج This is a model.رائع، لقد قمنا للتّو بتحضير بيانات النّموذج باستخدام متحكّم. صحيحٌ بأنّ هذه الطّريقة في ربط الخاصّية بالمرجع this مباشرة وليس فيها الكثير من التّعقيد، إلّا أنها تعطي انطباعًا خاطئًا بأنّ المتحكّم جزءٌ من النّموذج، وهذا غير صحيح، فالمتحكّم في الحقيقة يقوم بـتحضير النّموذج فقط. سيكون اختبار الشّيفرة وتتبّع أخطائها أكثر سهولةً عندما يتم الحدّ من الوصول إلى البيانات بمقدار ما يحتاج إليه العمل لا أكثر، كما أنّ الطّريقة السّابقة تضيف بعض الضجّة إلى شيفرة العرض، فجميع العناصر سيتم الوصول إليها عبر مرجع (reference) للمتحكّم. شيفرة العرض هي المكان الأكثر حساسيةً للضجيج في تطبيق ويب، فهي أوّل مكانٍ قد نبدأ فيه بفقد القدرة على فهم الهدف من الشّيفرة بلمحة سريعة. أخيرًا، المتحكّمات تعمل يدًا بيد مع المجال، لذا ولأهدافٍ تعليميّة سيكون من الأفضل رؤية مرجع (reference) للمجال وامتلاك القدرة على التّحكم به، ومع متحكّم كهذا سيكون بإمكاننا الكشف عن العناصر التي نحتاجها في العرض فقط، بدل الكشف عن المتحكّم بما فيه، وسنتّبع في هذا الكتاب هذه الطّريقة بالكشف الصّريح عن العناصر المستخدمة في العرض داخل المتحكّم. أوّل سؤالٍ يتبادر إلى الذّهن الآن هو: "كيف سنحصل على مرجعٍ للمجال؟"، هل سننشئ واحدًا عن طريق new أم سنطلب الحصول على واحدٍ بطريقة ما؟ حقن التابعيةسنحصل عليه عن طريق حقن التابعية، ربما تكون قد لاحظت أيضًا أنني لم أكتب أي شيفرة لإنشاء المتحكّم مثل: var controller = new MessageController(); مثلًا، فمن الذي يقوم بإنشاء المتحكّم المستخدم في العرض إذًا؟ Angular هي من يقوم بذلك طبعًا، فـAngular هي حاوية لتبادل التحكم Inversion of Control تدير دورة حياة مكونات التّطبيق، فعندما نحتاج إلى متحكّم جديد أو إلى مكوّنٍ آخر، ستقوم Angular ببنائه تلقائيًّا، وهذا يوفر الجهد، ولكنّ الأمر الأكثر أهمية هو أنه يسمح لـAngular بـحقن المصادر، أو التّبعيّات إلى المكوّن الجديد. scope$يحتاج متحكّمنا فقط إلى مُعامل يُسمّى scope$ وذلك بفضل إطار العمل الذي يُدار عن طريق حقن التّابعية، كما أنّ تسمية هذا المُعامل هامّة جدًّا. ويجب عليك أن تعرف خطورة تقصير شفرة JavaScript داخل مشروعك، فهذا قد يؤدي إلى تدمير آلية عمل حقن التّابعية. (ولكن لا تقلق، فهناك حلّ التفافيّ لهذه المشكلة، سنتطرّق إليه في فصل حقن التابعية). function MessageController($scope) { $scope.message = "This is a model."; }بإضافتنا للمعامل scope$ إلى تابع البناء نكون قد أخبرنا Angular بحاجتنا إلى مرجع لمجال العرض، والآن بدلًا من تعريف العنصر message داخل this (أي داخل المتحكّم)، قمنا بتعريفه مباشرةً داخل المجال. في المثال التّالي، قمنا بإزالة as controller من التّوجيه ng-controller، كما أنّ العبارة controller.message أصبحت فقط message وهي العنصر الوحيد الذي قمنا بربطه بالمجال. <p ng-controller="MessageController"> {{message}} </p> الناتج This is a model.رغم أن الطّريقتين تعملان بشكل صحيح، إلا أننا سنستخدم طريقة المرجع scope$، فكما ترى، حقن التّابعية هو جزء مكمّل لاستخدام Angular، ويجب أن يصير مألوفًا لنا. النموذج-العرض-المتحكم MVCيشير تعريف المتحكّم في المرجع الرسمي إلى أنّه يكشف “الوظائفيّة” للعرض، وقبل أن ننتقل إلى هذا الجزء يجدر بنا الحديث عن الفرق بين متحكّمات Angular وبين نموذج MVC التقليدي.(قد ترغب في تجاوز هذه الفقرة). تنصّ ويكيبيديا في مقال النّموذج-العرض-المتحكّم (MVC) على أنّ المتحكّم “يستلم المدخلات ويحوّلها إلى أوامر للنموذج أو للعرض.”، قد تكون عبارة “أوامر للنّموذج أو للعرض” صعبة الفهم في سياق الحديث عن Angular، فـAngular قامت بتبسيط نموذج MVC الخاص بها، باستخدام النّماذج الضّعيفة (anemic models) التي لا تحوي منطقًا برمجيًّا فيها. النّمط السّائد في Angular هذه الأيّام هو وضع كل منطق العمل، أو ما يُعرف أيضًا بمنطق النّطاق (domain logic) داخل المتحكّم. بعبارةٍ أخرى، تتّجه Angular نحو نموذج نحيل ومتحكّم سمين. إذا كنت تألف بعض الأنماط مثل نموذج النطاق الغنيّ (rich domain model) فربّما تجد طريقة Angular متخلّفةً بعض الشيء، أما أنا فأرى الأمر مجرّد طريقة لترتيب الأولويّات. فعند برمجة طرف المستخدم يكون الفرق الأكثر أهمّية هو بين شيفرة العرض التّريحية الموجّهة نحو المستند من جهة، وبين شيفرة JavaScript التي تتبع أسلوب الأوامر والمقادة بالبيانات والتي تعالج منطق العمل والبنية التحتية للتطبيق من جهة أخرى. أنا سعيدٌ لأن Angular ركّزت على ذلك فهذا انتصارٌ كبيرٌ لها، وقد يصبح ذات يومٍ فصل منطق العمل عن باقي مسؤوليات المتحكّم هو الأمر الأكثر أولويّة، وقد نرى توجّهات نحو نموذج أغنى. التوابعلنقم بكتابة متحكّم يكشف عن تابع بسيطٍ جدًّا، فقط لنختبر إمكانية استدعاء التوابع داخل العرض. لا بد من أنّك تذكر من الفصل الماضي أن Angular لا تسمح بتعريف التوابع داخل العرض. المتحكّم التّالي يقوم بإسناد تابع بسيط إلى عنصرٍ في العرض. function CountController($scope) { $scope.count = function() { return 12; } }ويمكننا استدعاء التّابع في العرض بكتابة شيفرة JavaScript عاديّة، اسم العنصر مع أقواس، فقط. <p ng-controller="CountController"> There are {{count()}} months in a year. </p>الناتج There are 12 months in a year.لاحظ أن التّابع لم يتم استدعاؤه ونسيانه بعد ذلك ببساطة، بل تمّ ربطه بالنّموذج. ما الذي يعنيه ذلك؟ ربّما بدأت بالتسليم بأن البنية التحتية في Angular هي الربط (binding)، ومرّة أخرى سأكرّر: لا تقوم Angular باستدعاء التّابع فقط عندما يتم إخراج العرض للمرة الأولى فقط، بل في أيّ وقتٍ يتم فيه تغيير النّموذج المرتبط، لنتمكّن من رؤية ذلك أثناء العمل سيتوجّب علينا كتابة تابع يستخدم عنصرًا من النّموذج. يستخدم التّابع add في المثال التّالي عنصرين في النّموذج، تم تعريفهما في المجال، وهما operand1 و operand1. ستقوم Angular باستدعاء التّابع وإخراج النتيجة كلّما تغيّر أحد العنصرين أو كليهما. function AdditionController($scope) { $scope.operand1 = 0; $scope.operand2 = 0; $scope.add = function() { return $scope.operand1 + $scope.operand2; } $scope.options = [0,1,2,3,4]; }لقد قمنا في الفصل الماضي بتغطية العديد من الأمثلة عن التّوجيه input في Angular، لذا سنستخدم الآن التّوجيه select لتغيير قيم النّموذج. لا بدّ من أنك لاحظت السّطر الأخير في الشّيفرة السابقة، حيث تمّ فيه تحضير نموذج خيارات options، وسنستخدم هذا النّموذج لبناء سلسلة داخل وسيط التّوجيه ng-options. سنستخدم العبارة x for x في بناء السّلسلة، ورغم أنها قد تبدو بلا فائدة لأنها تعيد عناصر السلسلة الأصلية كما هي، إلا أن التّوجيه يحتاج إلى كتابتها على أي حال.(عندما يكون النّموذج مكوّنًا من مصفوفة كائنات objects وهو الأكثر شيوعًا، يمكنك كتابة بانٍ للسّلسلة يقوم بإخراج العنصر name من الخيار المحدد، وذلك باستخدام x.name for x. <p ng-controller="AdditionController"> <select ng-model="operand1" ng-options="x for x in options"></select> + <select ng-model="operand2" ng-options="x for x in options"></select> = {{add()}} </p> إنه يعمل بشكل جيّد، ولكن بإمكاننا تحسين تصميم التّابع add عن طريق التّعميم، الذي سيكون مفيدًا إن أردنا استخدام التّابع مع وسطاء غير operand1 و operand2. فلنبدأ إذا بتعديل الشفرة ولنقم باستخراج الوسطاء من التابع. function AdditionController($scope) { $scope.number = 2; $scope.add = function(operand1, operand2) { return operand1 + operand2; } }يمكنك تمرير العناصر والقيم الفوريّة داخل العبارات، كما في JavaScript المعتادة. <p ng-controller="AdditionController"> {{add(number, 2)}} is not the same as {{add(number, "2")}} <br> 2 + 2 + 2 + 2 = {{add(2, add(2, add(2, 2)))}} </p>الناتج 4 is not the same as 22 2 + 2 + 2 + 2 = 8لنقم الآن بالكشف عن تابع استدعاء خلفي (callback) يمكنه معالجة عملٍ ما. الاستدعاءات الخلفية (Callbacks)في الفصل السابق، قمنا بتمرير عبارة إلى التّوجيه ng-click واستخدمناها للتّقليب بين قيمتين بوليانيتين للعنصر authorized، حيث قمنا بتهيئة القيمة الابتدائية للنموذج authorized باستخدام التّوجيه ng-init ثم تلاعبنا بقيمته عن طريق استدعاء خلفيّ سطريّ، فكتبنا "ng-click="authorized = !authorized، لنقم الآن بتعديل المثال عن طريق نقل التهيئة ووضع المتغيّر في مكانه الصحيح، في المتحكّم. function AuthController($scope) { $scope.authorized = true; $scope.toggle = function() { $scope.authorized = !$scope.authorized }; }والآن صار التّابع toggle متاحًا للاستخدام داخل المجال، والوسيط الذي سيتمّ تمريره للتوجيه ng-click سيبدو كأنه استدعاء للتابع: ()toggle ولكنه ليس كذلك كما ذكرنا سابقًا، إنها فقط سلسلة نصّيّة سيتم معالجتها لاحقًا عندما يقوم المستخدم بالنقر على الزر. <div ng-controller="AuthController"> <p> The secret code is <span ng-show="authorized">0123</span> <span ng-hide="authorized">not for you to see</span> </p> <input class="btn btn-xs btn-default" type="button" value="toggle" ng-click="toggle()"> </div>لا يزال المثال يعمل، والآن صار منطق التّابع toggle البسيط في مكانٍ أفضل. تشرح الكتب عادةً تقنيّاتٍ لإدارة التعقيدات باستخدام أمثلة شديدة البساطة لإيصال الإحساس العام بفائدة هذه التقنية، وقد قمنا بذلك هنا أيضًا. لقد طلبت إليك في الفصل الماضي أن تؤجّل حكمك على استخدام العبارات داخل نصوص HTML، فإذا كنت الآن قد أحببت طريقة Angular في تحسين نصوص HTML مع سلوك تفاعليّ، فقد تتساءل لم هذا التعقيد الزائد في المتحكّمات. أحد الأسباب التّقليدية لنقل الشّيفرة من سياقٍ معقّد(كالقالب) إلى واحدٍ أبسط (كالمتحكّم) هو تسهيل الاختبار وتصحيح الأخطاء لاحقًا. تتضح الفائدة من تسليم التعامل مع سلوك المستخدم إلى المتحكّم عندما نحتاج إلى كتابة شيفرات معقّدة، مثل مزامنة بيانات النّموذج مع المخدّم البعيد. خلاصةتعرفنا في هذا الفصل على JavaScript بداخل Angular، مكتوبة على شكل متحكّمات، والتي تتحمل مسؤولية تحضير البيانات للعرض كما ينصّ نمط MVC. تجعل المتحكّمات البيانات متاحةً للعرض عن طريق التصريح عن العناصر في كائن المجال scope$. في الفصل القادم سنأخذ نظرة أقرب لكائنات المجال، وسنتعرّف على كيفيّة تنظيمها في بنيةٍ هرميّة تتبع تقريبًا بنية الجزء الذي نعالجة في تطبيقنا ضمن مستند. ترجمة وبتصرّف للفصل الثالث من كتاب: Angular Basics لصاحبه: Chris Smith.
  5. تدير Angular الموارد باستخدام نظام الوحدات، ولهذا السّبب فهي تحتاج أيضًا إلى تقديم طريقةٍ للوصول إلى هذه الموارد المنظّمة ضمن حاويات (container-managed)، حيث تقوم Angular بذلك باستخدام نمطٍ إنشائيّ يُدعى حقن التبعية. إن لم يكن لديك معرفةٌ مسبقةٌ بهذا المفهوم فسأقوم هنا بأفضل ما لديّ لتلخيصه لك: لنفترض أنّك تحتاج إلى الحصول على مَوردٍ (resource) من Angular، المَورد هو الحاوية. للحصول عليه يجب أن تكتب تابعًا يُعرّف وسيطًا له نفس اسم هذا المَورد بالضّبط. تقوم الحاوية باكتشاف التّابع الذي كتبته، وتتعرّف على توافق الوسيط مع المَورد المطلوب، فتقوم بإنشاء نُسخةٍ (instance) من هذا المَورد (أو تقوم بأخذ النُّسخة المنفردة (singleton) من هذا المَورد، إن كان من النّوع المنفرد) ثُمّ تقوم باستدعاء التّابع الخاص بك وجعل هذه النّسخة هي قيمة الوسيط الخاص بالتابع. بما أنّ الحاوية هنا تلعب الدّور الفعّال (على عكس الطلب الذي تقوم به للحصول على نسخة من المَورد)، لذلك يُعتبر حقن التّابعيّة عكسًا للتّحكّم (inversion of control)، ويُقدّم على أنّه تطبيق لمبدأ Hollywood، "لا تكلّمنا، نحن سوف نكلِّمُك". أعتقد بأنّ مخترعي Angular قد اختاروا طريقة حقن التّابعيّة بسبب تاريخ Google الطّويل مع منصّة Java، بيئة برمجة ساكنة يقوم فيها حقنُ التّابعيّة بدورٍ فعّال في عمليّات تغيير الأنواع أثناء وقت التّشغيل. (لقد تخطّت Google الحدود في ذلك إلى درجة أنّها أنشأت إطار عمل Java خاصٍّ بها، Guice، الذي يعتمد على حقن التّابعيّة كُلّيًّا.) أمّا في JavaScript، وهي البيئة المرنة والديناميكيّة، حيث يمكن أن تتغيّر الأنواع أثناء وقت التّشغيل، فقد حظِيَ فيها أسلوب محدّد موضع الخدمة (service locator) البسيط والمباشَر بشعبيّة هائلة عن طريق الواجهة البرمجيّة لـCommonJS، وهي عبارة require المستخدمة في Node.js وbrowserify. والأكثر من ذلك، أنّ الطريقة البدائيّة في القيام بحقن التّابعيّة قد تبيّن أنّ لها نقطة ضعفٍ عند استخدامها في JavaScript من طرف العميل، وذلك بسبب تعديل أسماء الوُسطاء باستخدام المُقصّرات (minifiers). ولنستطيع التّعامل مع هذه المشكلة، من الضّروريّ أن توجد أداة بناءٍ بديلة، أو أن نتعلّم ونستخدم حواشي التّبعيّات، وسنصل إلى ذلك بعد قليل، ولكن لنتعرّف أوّلًا على النّموذج البدائيّ. التبعيات الضمنيةلن نستخدم خارج هذا الفصل للقيام بحقن التّبعيّة غير طريقة التّبعيّات الضّمنيّة لأنّها الأسهل بين جميع الطُّرق. كما ذكرت سابقًا، يمكننا جلب مرجعٍ لأحد الموارد المتاحة عن طريق وضعه كوسيطٍ في تابعنا الإنشائيّ، ولقد قمنا بذلك للمرّة الأولى عندما أضفنا الوسيط scope$ الذي يعطي تابع التّحكّم مرجعًا إلى كائن المجال المنظّمٍ ضمن حاوية (container-managed). يقوم نظام حقن التّبعيّة في Angular بالعثور على نسخةٍ للمَورد المطلوب (أو بإنشاء نسخةٍ لهذا المَورد) وتمريره إلى المتحكّم. لنرى مرّةً أخرى كيف نقوم بذلك على المَورد المدمج في Angular، الخدمة locale$. نحتاج إلى تعريف وحدتنا app لأنّ بعض أمثلة هذا الفصل تستخدم نظام الوحدات. angular.module('app', []);وبعد ذلك سنقوم بتحميل الوحدة عن طريق تمرير اسمها إلى التّوجيه ng-app. (أكرّر التّنبيه إلى أنّ الاسم app ليس إجباريًّا ويمكن استخدام أيّ اسم آخر.) <body ng-app="app"> <!-- الأمثلة توضع هنا --> </body>نحن الآن جاهزون للانطلاق مع مثالنا الأوّل، وبطريقةٍ مماثلةٍ لإضافة الوسيط scope$ سنضيف الوسيط locale$، وستلاحظ Angular هذين الوسيطين وتقوم بحقنهما. تقوم Angular بحقن الموارد داخل التّابع لأنّ هذا التّابع يمثّلُ متحكّمًا. angular.module('app') .controller('LocaleController', function($scope, $locale) { $scope.locale = $locale.id; });داخل جسم المتحكّم قمنا ببساطةٍ بإسناد المتغيّر locale الذي يمكننا تغيير اسمه إلى أيّ اسمٍ آخر، إلى العنصر id من الوسيط locale$ الذي لا يمكننا استخدام اسمٍ آخر له. <p ng-controller="LocaleController"> Your locale is <strong ng-bind="locale"></strong> </p>الناتج: Your locale is en-usيُفترض أن ترى شيئًا مماثلًا لعبارة "Your locale is en-us" في المخرجات. ما الذي سيحدث لو أنّك أضفت الوسيط myResource إلى تابع التّحكّم؟ هل عطّلت عمل المثال؟ هل يمكنك قراءة الخطأ في الـconsole الخاصة بـJavaScript في متصفّحك؟ تعرض أخطاء Angular غالبًا رابطا مفيدا، يمكنك عن طريق هذا الرابط أن تحصل على درسٍ رائع وقصير عن حلّ مشاكل حقن التّبعيّة، انقر على الرّابط السّابق واقرأ الشرح إن أردت. الحواشي (Annotations)تمثّلُ الحاشية في لغة برمجةٍ مثل Java، معلوماتٍ إضافيّة تُضاف إلى الشيفرة المصدريّة ويتجاهلها المترجم. أمّا في سياق الحديث عن حقن التّبعيّة في Angular، فتعني كلمة الحاشية التّصريح عن الموارد التي نريد حقنها بطريقةٍ صريحةٍ تحافظ على أسماء الوسطاء قصيرةً باستخدام أسلوب التّصغير (minification). (استخدام أداة البناء UglifyJS مثالٌ على أسلوب التّصغير.) لنتابع الآن طريقة Angular التي تسمح لنا فيها بإضافة الحواشي إلى التّبعيّات. ng-annotateمن الطرق الملائمة للتخلص من إزعاج مهمّة بناء ما، استخدام مهمّة بناءٍ أخرى. ستقوم أداة البناء ng-annotate بإضافة الحواشي للتّبعيّات، ومن ثمّ ستسمح لنا بمواصلة استخدام طريقة التّبعيّات الضّمنيّة التي شرحناها في الفقرة السّابقة. ستحتاج فقط إلى تشغيل ng-annotate قبل أن تُشغّل المقصّر (minifier) الخاصّ بك. هذه الأداة المركزيّة صُمّمت لتُستخدم عن طريق سطر الأوامر، إلّا أنّه يوجد غلافٌ لها لتفادي التّعامل مع سطر الأوامر، كما يوجد غلافٌ لمعظم أدوات البناء وحزم الأدوات، من ضمنها grunt-ng-annotate وgulp-ng-annotate وbrowserify-ngannotate وng-annotate-webpack-plugin. الحاشية السطريةهناك أسلوبان لكتابة الحواشي، وأكثرهما شُهرةً يُعرف باسم الحاشية السّطريّة (inline annotation)، وهي تتضمّن وضع تابع التّحكّم داخل مصفوفةٍ كما يلي. angular.module('app') .controller('LocaleController', ['$scope', '$locale', function(s, l) { s.locale = l.id; }]);الناتج: Your locale is en-usفي المثال السّابق، قُمت بمحاكاة تأثير التّقصير عن طريق تغيير أسماء الوُسطاء من scope$ و locale$ إلى s وl بالترتيب. بالطّبع لا يمكن لـAngular أن تجد مَوردين لهما الأسماء s وl لو اعتمدنا على أسلوب إضافة الحواشي الضّمنيّ، ولكن هنا، ولأنّ المصفوفة تحوي أسماء الوسطاء الحقيقيّين ستتمكّن من حقنهم بنجاح. إضافة الحاشية بواسطة inject$إن كان قد انتابك شعورٌ بأن طريقة إضافة الحواشي السّطريّة، قبيحة، فالأرجح أنك ستجد الطريقة البديلة هذه أكثر قبحًا. فهي تعتمد على إنشاء عنصرٍ ذا اسمٍ مخصّص، inject$، في التّابع الإنشائيّ، وهذا سبب تسمية الطّريقة بهذا الاسم. var LocaleController = function(s, l) { s.locale = l.id; }; LocaleController['$inject'] = ['$scope', '$locale']; angular.module('app') .controller('LocaleController', LocaleController);الناتج: Your locale is en-usالمهمّ أنّك الآن تعرف الخيارات المتاحة للقيام بإضافة الحواشي. angular.injectorأرجو أن تكون عند هذه النّقطة قد قمت بإضافة ng-annotate إلى بُنيتك، لتتمكّن من استخدام الأسلوب البدائيّ في التّبعيّات الضّمنيّة التي ستراها في هذه السلسلة دون مشاكل. على أيّ حال، إن لم تكن قد قمت بذلك، لديّ اقتراح لك، إلّا أنّه ليس اقتراحًا جادًّا: قم بكتابة تابع require الخاصّ بك، وأفصح عن التّبعيّات الّتي تريد ضمن عمليّة البحث المباشر عن الخدمات، وذلك بدلًا من استخدام أسلوب حقن التّبعيّة. يمكنك القيام بذلك عن طريق استدعاء تابع angular.injector مباشرةً، وعليك تمرير وسيط وحيدٍ إليه هو مصفوفةٌ فيها أسماء الوحدات التي ترغب بالبحث ضمنها، ويجب عليك تمرير اسم الوحدة ng دومًا وجعلها في بداية القائمة. var require = function(name) { return angular.injector(['ng','app']).get(name); }; angular.module('app') .controller('LocaleController', ['$scope', function($scope) { var $locale = require('$locale'); $scope.locale = $locale.id; }]);الناتج: Your locale is en-usلاحظ أنّ المثال لايزال يعتمد على حقن التّبعيّة في تمرير كائن المجال الصّحيح للمتحكّم، سأسعى في الفقرة القادمة لأبيّن لك أحد أهمّ المشاكل العمليّة مع الحواشي في الأنظمة الضّخمة، وذلك خشية أن يتبادر إلى ذهنك بأنّ الاستثناء الّذي واجهناه للتّو يلغي الحاجة إلى تبنّي طريقة محدّد موضع الخدمة. مخاطرالمثال التّالي سيستبق الأحداث، ويأخذنا إلى الفصل القادم، الخدمات. سنستخدم في هذا المثال التّابع factory، ورغم أنّك لم تألف استخدامه من قبل إلّا أنّه بإمكانك تخمين وظيفته، فهو يقوم بإعداد مصنعٍ للمكوّن باستخدام نظام الوحدات. لاحظ أيضًا أنّ الخدمة http$ (التي سنناقشها في فصلٍ لاحق HTTP) ستكون خدمةً نموذجيّةً ومثالًا من الحياة العمليّة لاستخدام حقن التّبعيّة داخل خدماتٍ كهذه. angular.module('app') .factory('fullPrice', ['$http', function($http) { return function() { // Use $http to fetch remote data. return 100; } }]) .factory('discountPrice', ['$http', function($http) { return function() { // Use $http to fetch remote data. return 40; } }]);استلهمتُ المثال التّالي من تطبيق Angular حقيقيّ، حيث استُبدلت التّبعيّات بقائمةً طويلةً من الخدمات المدمجة في Angular، ولكنّ طول القائمة هو نفسه تقريبًا. angular.module('app') .controller('PriceController', ['$scope', '$anchorScroll', '$animate', '$cacheFactory', '$compile', '$controller', '$document', '$exceptionHandler', '$filter', '$http', '$httpBackend', '$interpolate', '$interval', 'fullPrice', 'discountPrice', '$locale', '$location', '$log', '$parse', '$q', '$rootElement', '$rootScope', '$sce', '$sceDelegate', '$templateCache', '$timeout', '$window', function( $scope, $anchorScroll, $animate, $cacheFactory, $compile, $controller, $document, $exceptionHandler, $filter, $http, $httpBackend, $interpolate, $interval, discountPrice, fullPrice, $locale, $location, $log, $parse, $q, $rootElement, $rootScope, $sce, $sceDelegate, $templateCache, $timeout, $window) { $scope.fullPrice = fullPrice(); $scope.discountPrice = discountPrice(); }]);من الواضح أنني اختصرت جسم المتحكّم PriceController وكذلك اختصرت شيفرة العرض التّالية. <table ng-controller="PriceController"> <tr> <td>Full price:</td> <td>{{fullPrice}}</td> </tr> <tr> <td>Discount price:</td> <td>{{discountPrice}}</td> </tr> </table>الناتج: Full price: 40 Discount price: 100لقد تعمّدت القيام بخطأٍ في المثال السابق، فالمفترض أن يكون السعر الكلّي أكبر دومًا من السّعر المخفّض، ولكنّهما انعكسا لسببٍ ما، والمشكلة ليست في شيفرة العرض أو في جسم المتحكّم، هل يمكنك إيجادها؟ ماذا تستنتج من ذلك بخصوص كتابة حاشية التّبعيّات يدويًّا في المشاريع الحقيقيّة؟ خاتمةهذا هو الفصل الثّاني من أصل ثلاثة فصول في هذه السلسلة تغطّي البنية التّحتيّة لـAngular الخاصّة بإدارة شيفرة التّطبيق. الفصل الأوّل، الوحدات، بيّنَ كيف سنقوم بتهيئة خشبة المسرح الّتي سيقف عليها الممثّلون ليقوم كلٌّ منهم بدوره. وفي هذا الفصل شرحنا ببعض التّفصيل الآليّات المتاحة لجعل كلِّ ممثّلٍ يقفُ في مكانه الصّحيح. أمّا الفصل الثّالث ضمن هذا المجال، الخدمات، سيشرح كيفيّة إنشاء الممثّلين أنفسهم. ترجمة وبتصرّف للفصل السابع من كتاب: Angular Basics لصاحبه: Chris Smith.
×
×
  • أضف...