Adnane Kadri

و عليكم السلام و رحمة الله . يحتمل أن يكون ذلك بسبب نسخة الـ MySql التي تستخدمها . فالسياق قد يكون غير مدعوم بعد في نسخ متأخرة من MySql أقل من النسخة الثامنة (الحالية) . يمكنك على كل حال إستبدال الإستعلام الذي لديك بالتالي : ALTER TABLE tableName CHANGE oldcolname newcolname datatype(length); أو مفصلا : ALTER TABLE `dbName`.`tableName` CHANGE COLUMN `old_columnName` `new_columnName` VARCHAR(45) NULL DEFAULT NULL;

معروف أن العناصر و الوسوم <meta> ,تعرف أيضا بـ meta level tags, تمثل بيانات وصفية لا يمكن تمثيلها باستخدام عناصر HTML المتعلقة بالبيانات الوصفية من مثل <link> أو <title> . و تعتبر http-equiv أحد الخواص التي من الممكن أن تتخذها وسوم الـ meta هاته , هاته الخاصية تعطى قيمة ما يمكنها تعديل سلوك الخادوم أو المتصفح . وتكون قيمة هذه الخاصية موجودة ضمن الخاصية content . و من بين القيم التي من الممكن أن تأخذها الخاصية هي القيمة X-UA-Compatible , تخص هاته القيمة متصفحات IE . فإبتداءا من Internet Explorer 8 ، أصبح يمكنك إجبار مستعرض Internet Explorer على استخدام محرك Internet Explorer آخر أقدم لتفسير صفحة Html الخاصة بك . يمكن أن تأخذ الخاصية content الموافقة لهاته الخاصية القيم التالية : <meta http-equiv="X-UA-Compatible" content="IE=5" /> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> <meta http-equiv="X-UA-Compatible" content="IE=7.5" /> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" /> <meta http-equiv="X-UA-Compatible" content="IE=8" /> <meta http-equiv="X-UA-Compatible" content="IE=100" /> <meta http-equiv="X-UA-Compatible" content="IE=Edge" /> <meta http-equiv="X-UA-Compatible" content="IE=9; IE=8; IE=5" > كل قيمة تشير إلى نسخة مستهدفة من نسخ انترنت اكسبلورر . و بالطبع , لا يعد استخدام X-UA-Compatible حلاً نهائيًا لأنه ليس مدعوما و متوافقا مع جميع متصفحات Internet Explorer , فمثلما تم الإشارة الخاصية ليست مدعومة إلا بعد النسخة 8 . توثيق العنصر meta هنا .

يمكن تعريف الـ API , اختصارا لـ Application Programming Interface ترجمة عن واجهة تطبيقات برمجية أو الواجهة البرمجة للتطبيق , كـمجموع القواعد التي تحدد كيفية اتصال تطبيقات أو واجهات , أو حتى الأجهزة ببعضها البعض . شائع بناءها في تطبيقات الويب لفصل الواجهة الخلفية تماما عن شيفرات الواجهة الأمامية يتوفير نقاط وصول أو end points للوصول إلى مصادر معينة أو تطبيق أفعال CRUD بسهولة (Create, Read ,Update , Delete ) . و يتم ذلك عن طريق إخفاء تعقيد منطق عمل وظيفة أو دالة أو تابع و تصدير طريقة بسيطة للوصول إليه و التعامل معه , يعطي هذا مرونة أكبر و قابلية أكثر للتحكم في التطبيق بواجهتيه : الأمامية و الخلفية . أما عن REST API فهي واجهة برمجة تطبيقات تتوافق مع مبادئ تصميم REST ، أو كما يعرف بالـ representational state transfer architectural style . و لهذا السبب ، يُشار أحيانًا إلى واجهات برمجة تطبيقات REST إلى واجهات برمجة تطبيقات RESTful كصفة عن REST . تتواصل هاته الـ REST APIs عبر طلبات HTTP لأداء وظائف قاعدة البيانات القياسية مثل إنشاء وقراءة وتحديث وحذف السجلات (المعروفة أيضًا باسم CRUD) داخل مورد ما . على سبيل المثال : قد تستخدم واجهة برمجة تطبيقات REST كلا من التالي : طلب GET لاسترداد الموظفين في قاعدة بياناتنا . طلب POST لإنشاء موظف جديد . طلب PUT أو PATCH لتحديث بيانات موظف . طلب DELETE لحذف بيانات موظف . و يعبر عن ذلك بـ : GET https://your_domain.dm/api/v.x/teachers POST https://your_domain.dm/api/v.x/teachers PATCH https://your_domain.dm/api/v.x/teachers/{teacher_id DELETE https::/your_domain.dm/api/v.x/teachers/{teacher_id} يتم وراء هاته الروابط أو النقاط سهلة الوصول إخفاء كل تعقيد , من الإتصال بقواعد البيانات و التحقق من الطلبية و معالجتها و إعادة الرد عليها . يمكن تلخيص مجموعة مبادئ REST التي تعطي صفة الـ RESTful لكل واجهة برمجية تلتزم بها كالتالي : الواجهة الموحدة (uniform interface) : يجب أن تبدو جميع طلبيات واجهة برمجية ما للمورد نفسه بنفس الشكل متبعة نفس النسق , أي أن كل من الطلبات و الشكل العام لنقاط الوصول و الردود و غيرها يجب أن تتبع نسقا موحدا . فصل واجهة العميل عن واجهة الخادم (Server - Client أو Client-server decoupling) : يفرض نمط تصميم عميل - خادم مبدأ فصل الاهتمامات التي تساعد مكونات العميل والخادم على التطور بشكل مستقل . و ذلك من خلال فصل اهتمامات واجهة المستخدم (العميل) عن اهتمامات تخزين و معالجة البيانات (الخادم) . عدمية الحالة (Stateless أو Statelessness) : يجب أن تكون واجهات برمجة تطبيقات REST عديمة الحالة ، مما يعني أن كل طلب يحتاج إلى تضمين جميع المعلومات اللازمة لمعالجته. بمعنى آخر ، لا تتطلب واجهات برمجة تطبيقات REST أي جلسات من جانب الخادم. لا يُسمح لتطبيقات الخادم بتخزين أي بيانات متعلقة بطلب العميل . قابلية التخزين بشكل مؤقت (Cacheability أو Cacheable) : بحيث يتطلب أن يتم تصنيف البيانات الموجودة في الاستجابة بشكل ضمني أو صريح على أنها قابلة للتخزين المؤقت أو غير قابلة للتخزين المؤقت . إذا كانت الاستجابة قابلة للتخزين المؤقت ، فسيتم منح تطبيق العميل الحق في إعادة استخدام بيانات الاستجابة لاحقًا ، للطلبات المكافئة ولفترة زمنية محددة . مثل : طلبات سجل الموظفين يتم تخزينها في الذاكرة المؤقتة و لا حاجة لإعادة تنفيذ الإستعلام إلا كل ساعة مثلا . في حين أن جلب معلومات سجل التعاملات أو المدفوعات غير قابل للتخزين بشكل مؤقت . نظم الوسطاء (Layered system) : ففي REST APIs ، تمر كل من المكالمات والاستجابات عبر طبقات مختلفة. و كقاعدة عامة ، لا يفترض من تطبيقات العميل والخادم أن تتصل ببعضها البعض مباشرة. قد يكون هناك عدد من الوسطاء المختلفين في حلقة الاتصال. فيجب تصميم واجهات برمجة تطبيقات REST بحيث لا يمكن للعميل أو الخادم معرفة ما إذا كان يتواصل مع التطبيق النهائي أو الوسيط . مفاهيم مثل الطبقات الوسيطة أو الـ middlewares شائعة جدا بهذا الخصوص . يمكنك الإطلاع على هذا السؤال بشأن المبدأين Stateless و Cacheable هنا . كما يمكنك التعرف أكثر على أسباب التوجه إلى تطوير الخدمات في الواجهات الخلفية كـ API هنا .

لنقم بتفكيك الإستعلام لفهمه أولا : نحتاج تحديد معرف الشركة التي لها أكبر عدد موظفين سابق , و ذلك عن طريق قراءة أكثر قيمة معروفة أو مكررة في جدول الموظفين people . يترجم إلى : SELECT PREV_COMPANY_ID FROM people GROUP BY PREV_COMPANY_ID ORDER BY COUNT(PREV_COMPANY_ID) DESC LIMIT 1; بناء على نتيجة الإستعلام السابق , نحتاج تحديد وجلب معلومات هاته الشركة , و يكون ذلك عن طريق القراءة من جدول الشركات companies : SELECT * FROM companies WHERE id = TARGET_RESULTED_ID حيث أن القيمة TARGET_RESULTED_ID هي القيمة الناتجة عن الإستعلام السابق . ثم بمساعدة الإستعلام الفرعي أو الـ sub Query لنقم بدمجهما معا ليكونا على النحو التالي : SELECT * FROM companies WHERE id = ( SELECT company_id FROM people GROUP BY company_id ORDER BY COUNT(company_id) DESC LIMIT 1 ) و ما سيقوم به هذا الإستعلام هو ببساطة كالتالي : جلب معلومات الشركة التي معرفها يساوي ( أكثر معرف شركة مكرر في جدول الموظفين ) . و بعبارة أخرى :

كحل نهائي لجميع المشاكل يقترح إستعمال باني إستعلامات عوضا عن إستعلامات SQL جاهزة من الواجهة DB , و ذلك لأن العديد من الإستعلامات التي نكتبها قد لا تعمل مع نظم إدارة قواعد بيانات أخرى تختلف عن تلك التي اختبرنا عليها إستعلاماتنا الأولى . و إلا فإننا سنحتاج تنقيح كل إستعلاماتنا لتلائم بيئة إنتاجنا . إستعمال Eloquent سيحد من هذا المشكل . فمثال مثل الذي لديك : DB::select( 'SELECT id FROM teachers WHERE (subject_id = ? AND levels = ?) OR EXISTS (SELECT id FROM users WHERE name = ? AND phone = ?)', [$request->subject, json_encode($request->levels), $request->name, $request->mobile] ); يصبح : DB::table('teachers') ->where('subject_id', $subject) ->where('levels',json_decode($request->levels)) ->orWhereExists(function($query) { DB::table('users') ->where('name',$request->name) ->where('phone',$request->mobile) ->select('id'); }) ->select('id') ->get(); و هكذا .. يعطي هذا مرونة أكبر و قابلية أكثر للتلائم مع كامل النظم . تعرف على المبادئ الأساسيّة لإطار العمل Eloquent ORM .

لاحظ أن عنصر الفقرة التالية : <p>Unlimited Possibilities</p> يمتد على عرض أكثر من عرض الحاوي له , و ذلك حتى يحافظ على التخطيط الشبكي grid layout للعنصر الحاوي له بالصنف التالي : intro__container . يسبب تمدده على عرض أكبر من عرض الصفحة امتلاكه للخاصية التالية : .intro p:last-of-type { font-size: 3.8rem; } فلو تقم بتقليل حجم الخط الذي يمتلكه ستلاحظ عودة الصفحة لحجمها الطبيعي , و ذلك لعدم إمتداد الحاوي الشبكي على عرض أكبر من عرض الصفحة . و ليكن مثلا حجم الخط 2.1rem . جعل أحجام الخطوط تجاوبية يجب أخذه بالإعتبار أيضا , و لذلك أفضل تقليل حجم النص لعنصر الفقرة عوضا عن إعطاء العنصر body القيمة fit-content للخاصية min-width . فهاته القيمة ليست مدعومة بعد من قبل كامل متصفحات الويب .

يبدوا أن العنصر body لا يأخذ كامل عرض الصفحة في الشاشات الأقل من 343 بكسل . إعطاء العنصر body القيمة fit-content في خاصية العرض الأدنى للعنصر min-width قام بحل المشكل لدي: body{ min-width: fit-content; } توثيق الخاصية : هنا .

يمكنك أيضا ذلك عن طريق إستعمال التابع replace لإستبدال كل الفواصل الناتجة عن تحويل المصفوفة إلى سلسلة نصية بإستعمال toString كالتالي : var arr = ['hsoub' ,'academy' ,'is' ,'cool']; console.log( arr.toString().replace(/,/g ,' ') ); // hsoub academy is cool كما يمكنك إستعمال الباني الخاص بـالصنف String كالتالي : var arr = ['hsoub' ,'academy' ,'is' ,'cool']; console.log( String(arr).replace(/,/g,' ') ); // hsoub academy is cool و لكن عيب هاتين الطريقتين هو في إحتمالية إحتواء أحد عناصر المصفوفة فاصلة مثل "h,soub" . لن يتم إعتبارها و سيتم إستبدالها بفراغ بكل حال من الأحوال . و كحل لهاته المشكلة يمكنك إستعمال بدلا من ذلك الطريقة التالية : تقليل المصفوفة إلى قيمة واحدة عن طريق التابع reduce بإستعمال فاصل مخصص كالتالي : var arr = ['hsoub' ,'academy' ,'is' ,'cool,' ,'awesome' ,'and great!']; arr.reduce((str, a) => { return str +' '+ a }); // hsoub academy is cool, awesome and great! يمكنك الإطلاع على كل من : توثيق التابع replace . توثيق الكائن String . توثيق التابع reduce .

نعم بالضبط . و أضيف على ذلك , التوابع أيضا . فمن الممكن تغليف التوابع و جعلها غير قابلة للوصول إلا من خلال الصنف نفسه أيضا . كما أظن أن الحاجة لذلك في مسارك و أثناء تطبيقك العملي ستقوم بتوضيح ذلك أكثر لك . تعرف الكلمات public , private و protected في الوسط البرمجي كمحددات وصول ترجمة عن Access Modifiers بحيث تحدد هاته الكلمات الخواص و التوابع التي يمكن الوصول إليها . بحيث أن : public : تعني أن الوصول إليها قابل في كل مكان . protected : تعني أن الوصول محمي فقط داخل الصنف نفسه , و من داخل أي أصناف ترث هذا الصنف أيضا . private : تعني أن الوصول لا يتم إلا من خلال الصنف الذي يحدد هاته الخاصية أو أحد توابعه العامة . .

و عليكم السلام و رحمة الله تعالى و بركاته . لنقم بفهم التغليف كالتالي : التغليف ترجمة عن encapsulation هو ميكانيزمة و طريقة لحماية الخواص و التوابع التابعة لصنف ما من التعديل المباشر عليها مع إمكانية إستعمال تابع معين للصنف لتعديل ذلك . و لكن ما الذي يعنيه ذلك ؟ لنأخذ التالي لفهم الحاجة من التغليف أساسا : تقوم شركات صنع سيارات بتوفير مقود في سياراتها كآلة للتحكم في إتجاهات سير السيارة , و من جانب اخر تقوم بإخفاء التعقيد وراء هاته العملية . أي أنها تقوم بتغليف و تغطية كل ما يتعلق بكيفية سيرها و توفير طريقة بسيطة لتغيير خاصية الإتجاه في السيارة . فهل يبدوا من المنطقي أن نقوم بتوصيل سلك بسلك أو تطبيق قوة ميكانيكية كل مرة نريد فيها تغيير اتجاه سيارة ؟ نفس الشيء ينطبق على التغليف في البرمجة الشيئية , فتغيير الخاصية مباشرة لا يكون سليما أحيانا , و قد يتعلق بمنطق عمل توابع أخرى تتأثر بتغير قيمة هاته الخاصية . و لكن تغييرها عن طريق توفير تابع يقوم بتحمل و اعتبار تبعات هذا التعديل حل نهائي للمشكلة . مثال عملي : ليكن الصنف DBInteract , المسؤول عن التفاعل مع قاعدة البيانات عن طريق عمليات CRUD العادية كالتالي : class DBInteract{ public $db_password = '68426123'; public $db_username = 'root'; public $db_name = 'my-db'; public function insert(string $table ,array $data) { } public function update(string $table ,array $data) { } public function delete(string $table) { } public function select(string $table ,array $rows) { } } و لنفرض أن كل من التوابع المعرفة تحمل شيفرات يمكن فهم وظيفتها عن طريق اسماءها الدلالية . و لنقل أننا نحتاج إدراج مهمة جديدة بجدول tasks في قاعدة البيانات بإسم my-db . أي أن العملية ستكون كالتالي : $db_class = new DBInteract(); $db_class->insert('tasks' ,$data); و منطقي هو أن التابع insert المسؤول عن عملية الإنشاء سيقوم بإستعمال الخواص التالية لمصادقة إتصاله مع قواعد البيانات : public $db_password = '68426123'; public $db_username = 'root'; public $db_name = 'my-db'; المشكلة هنا , هي أن هاته الخواص قابلة للوصول بشكل عادي عن طريق إستدعاء مباشر من أي كائن عن الصنف DBInteract . فلو أن مستخدما ما لصنفنا الجاهز DBInteract قام بتغيير الخاصية db_name بعد عشرات من إستعلامات الإنشاء و القراءة و الحذف و التعديل بمجرد سطر واحد : $db_class->db_name = 'new-db-name'; و لنقل أن بيانات المصادقة تحتاج فحصا قبل إعادة التعيين مثل أن يكون اسم قاعدة بياناتنا سلسلة نصية , و اسم مستخدمنا ليس قيمة فارغة , و كلمة سرنا تشكيلة أرقام . في حالة تعطل ذلك سيخل هذا بعمل كل من التوابع insert , update , delete , select . و هو ما لا نريده طبعا . و لحل المشكل لن نقوم إلا بتغليف هاته الخواص بإستعمال الكلمة المفتاحية private و إنشاء تابع جديد يمكننا من تغيير بيانات المصادقة هاته بطريقة سليمة لا تؤثر على عمل باقي التوابع . و ليكن مثلا : class DBInteract{ private $db_password = '68426123'; private $db_username = 'root'; private $db_name = 'my-db'; public function changeCreds($pass , $un , $db) { if(is_string($db) && is_numeric($pass) && !is_null($un)){ $this->db_password = $pass; $this->db_username = $un; $this->db_name = $db; } } public function insert(string $table ,array $data) { } public function update(string $table ,array $data) { } public function delete(string $table) { } public function select(string $table ,array $rows) { } } الان لو حاول شخص ما تغيير أحد بيانات المصادقة عن طريق مباشرة فهو لن يستطيع , و ستظهر له رسالة تخبره بذلك : cannot access private property و قس على ذلك العديد من الأمثلة و الوضعيات الأخرى التي تكون فكرة التغليف حلا فيها .

و عليكم السلام و رحمة الله . التطبيق العملي و بناء ما بني بالفعل لا يعني مماثلة طرق بناءه الأولى أو السير على نفس طريقة مصممها الأول , فما تراه أنت مناسبا أن يتم عمله بتخطيط شبكي Grid Layout يمكن أن أفضل عمله بـخواص الصندوق المرن flexbox مثلا و قس على ذلك الكثير . فقد نختلف في الطرق و نتفق في النتيجة . و هذا ما هو إلا نتيجة طبيعية للتنوع و التضارب بين الطرق , الأدوات و مختلف الفلسفات التي توفرها طبيعة المجال و حجمه و حجم مجتمعه . كما أني أهنئك على عدم النظر أو اختلاس كود الاخرين في مرحلة بناء و تقليد قالب ما , فهذا ما ينمي قدرة النمذجة لديك , أو ترجمة الواقع إلى شيفرة و هيكلية , و ذلك وفق طريقتك و فهمك الخاصتين . يعطيك هذا ثقة أكبر بالشيفرة التي تكتبها و إطلاعا أكبر عليها , و بالتالي تحكما أكبر و أوسع . و هو شيء لطالما ستحتاج إليه طول مسيرتك الدراسية أو العملية . و لا يعني هذا طبعا عدم الإطلاع على شيفرة الاخر و طريقة عمله للفكرة تماما أو بعد التطبيق أيضا , فإن كانت قد بنيت بأدوات تفهمها و تعرفها تأكد أن تقوم بمحاولة فهمها و إستيعابها , و إلا فإن نمذجتك لفكرة الغير بطريقتك كاف . و لذلك فإنه التوجه و البحث عن ما بني بالمهارات التي تكتسبها أفضل و أولى من تقليد أي قالب أو تطبيق , فهذا من شأنه أن ينمي قدراتك أيضا , فتأخذ بدل الطريقة طريقتين . أما عن طرق للتمرن على تصميم المواقع بـ html و css و javascript فإليك بعض النقاط التي أحب الإشارة إليها دوما : قم بتقليد التصاميم و القوالب الجاهزة , و ذلك كتغذية بصرية و تطويرا لقدرتك على النمذجة . قم ببناء تطبيقات بسيطة ( سيتم اقتراح بضعة تطبيقات فيما سيأتي ) , و ذلك لحاجتك لتطوير قدرتك على إستخدام مفاهيم اللغة و أساسياتها و خصوصا في الجافاسكربت . حاول فهم المشاكل التي تصادفها , وصفها , مناقشتها و تبسيطها و البحث عن ما يتعلق بها و قراءة اراء الاخرين و أكوادهم بشأنها . كن نقديا في انتقاء الأفكار , فبدل البحث عن "كيفية فعل كذا" ابحث عن "أفضل الطرق لفعل كذا". استعن بأوراق و ملصقات ملاحظات لتبسيط كل ما يصعب عليك . قم بتجزئة الأفكار إلى الكبيرة إلى أصغر و إلى أخرى أدق و هكذا , أي أنه لا يجب عليك رؤية التطبيق ككل في محاولة لفهمه , بل قم بتجزئته و تفكيك مفاهيمه . و نفس الشيء ينطبق على قوالب المواقع أو أية مجسمات أو تركيبات تظهر صعبة التشكيل بها . إليك 7 تطبيقات يمكنك تطبيق مهاراتك عليها : ساعة رقمية عن طريق الجافاسكربت . ساعة دائرية عن طريق الجافاسكربت و تحويلات الـ CSS . الة حاسبة عن طريق الجافاسكربت . تطبيق إدارة قائمة مهام To Do List . مولد ألوان عشوائية . تطبيق معرض صور Gallery . تطبيق عارض شرائح Slide Show .

تعرف PDO في PHP إختصارا لـ PHP Data Object ترجمة عن كائن بيانات PHP بإمتداد PHP . و قبل تعريفه كإمتداد ينبغي أولا فهم ما هو الإمتداد .. في السابق تم إستخدام ملف php واحد للتعامل مع قواعد البيانات , هذا الملف كان قد امتلك لاحقة dll. . تدعى هاته الملفات بالإمتدادات , بحيث أن امتدادت الـ PHP هاته يتم تعريفها كإضافات و الإشارة إليها في ملف php.ini . مثل ما أرفق المدرب أسامة في تعليق سابق : ;extension=php_pdo_firebird.dll ;extension=php_pdo_mssql.dll extension=php_pdo_mysql.dll extension=php_pdo_oci.dll extension=php_pdo_oci8.dll ;extension=php_pdo_odbc.dll extension=php_pdo_pgsql.dll extension=php_pdo_sqlite.dll بحيث يوفر امتداد (PDO) واجهة خفيفة الوزن ومتسقة للوصول إلى قواعد البيانات في PHP و التعامل معها عن طريق طبقة مجردة للوصول إلى البيانات . مما يعني : أنه بغض النظر عن قاعدة البيانات التي تستخدمها ، فإنك تستخدم نفس الوظائف لإصدار الاستعلامات وجلب البيانات و هو شيء لم يكن معروفا قبل ظهورها , و إلا فقد كان بصعوبة بالغة . أي أن تغيير الإتصال من MySql إلى Oracle أو postgresql لن يكون إلا بإعداد ذلك في ملف php.ini , ولن يضطرك الحال إلى تعديل إستعلاماتك أو طريقة قراءتك من قواعد البيانات ما دمت تستخدم كائنات PDO لكل ذلك .

مثلما يمكنك إستعمال واحدة من الحزم الجاهزة لذلك , يمكنك بكل حال من الأحوال نمذجة الفكرة و تطبيقها بخصوصية عالية . لنقل أن الفكرة تتبع المنطق التالي : HTML : تعريف عنصر قائمة منسدلة select , تحمل كخيارات مجموعة الدول . بحيث يحمل كل خيار خاصية value بقيمة الرقم الدولي المرافق لهاته الدولة . تعريف حقل إدخال نصي . 2. JS : يجب إضافة حدث عند الكتابة في حقل الإدخال النصي , ففي حالة مطابقة النص المدخل من طرف المستخدم لقيمة خاصية value لخيار ما في القائمة المنسدلة , يتم تحديده تلقائيا . مثال عملي : يمكنك بأي حال من الأحوال طباعة قائمة الدول بأي طريقة , و سيتم إختيار تكرار foreach في لارافيل للقيام بذلك . كما أن تنسيق العنصر يتم بخصوصية عالية , و لذلك سنستخدم صفوف بوتستراب كمثال . لنقم بتعريف الهيكلية التالية : <div class="col-12 d-flex flex-wrap"> <select id="countryList" class="col-lg-3 form-control"> @foreach ($countries as $country) <option value="{{ $country->phonecode }}"> {{ $country->name }} </option> @endforeach </select> <input type="text" id="typeNumber" class="form-control col-lg-9" placeholder="قم بإدخال رقم هاتفك مرفقا بالكود الدولي"> </div> ثم لنقم بإضافة شيفرات الجافاسكربت لتقوم بالوظائف الموصوفة سابقا , و ذلك كالتالي : var typeNumber = document.querySelector('#typeNumber'), countryList = document.querySelector('#countryList'); typeNumber.addEventListener('keypress' , function(){ var countryCode = this.value; if(!! document.querySelector('option[value="' + countryCode + '"]')) { countryList.value = countryCode; } }); أو بسياق الـ jQuery : var typeNumber = $('#typeNumber'), countryList = $('#countryList'); typeNumber.on('keypress' , function(){ var countryCode = $(this).val(); if(!! $('option[value="' + countryCode + '"]')) { countryList.val(countryCode); } }); و بشكل عام , سيمكنك تخصيص منطق عملها وفق احتياجك ووفق ما يلائم فكرتك , كأن تقوم بإعادة تشكيل هيكلية الـ HTML لتتضمن صورة مصغرة للعلم الوطني لكل دولة أو تغير طريقة التحديد لكل عنصر أو أية فكرة أخرى قد يحتاجها أي تعديل . يمكنك التحصل على قائمة بإسم الدولة مرافقا لها رقمها الدولي من هنا .

و عليكم السلام و رحمة الله بداية أدعوك إلى عدم القلق بشأن مواجهة صعوبة في الفهم أو الإحساس بعدم وصول الفكرة , فهذا الأمر شائع جدا في الأوساط البرمجية و ستحتاج أن تتعلم الصبر في التعلم قبل كل شيء . أما عن سؤالك بخصوص تعلم HTML و CSS لتعلم جافاسكربت فإن تعلمهما ليس إلزاميا لتعلم الجافاسكربت , و ذلك لكونها لغة مستقلة بمنطقها و سياقها الخاص و بطريقة تعاملها الخاصة , و لكن تعلم الـ HTML و الـ CSS قبلها أو معها سيأخذ بتعلمها إلى بعد اخر , بعيدا عن التجريد الذي تعتمده لغات البرمجة خصوصا و أنك تلتمس نتائج شيفرة الجافاسكربت على شاشة المتصفح . و هذا لا يعني بالضرورة تطبيق ما يعرف بنموذج كائن الوثيقة DOM أو نموذج كائن المتصفح BOM . بل المقصود هو تطبيقك لمفاهيم الجافاسكربت كالتكرارات و المتغيرات و الدوال و غيرها بطريقة تلخص نتائجها في عرض و تلاعب على الشاشة . أي أن الإجابة بإختصار على السؤال "هل يجب تعلم HTML و CSS قبل الجافاسكربت؟" هي "لا ليس بالضرورة , و لكنها تجعل عملية تعلمها أبسط , أسرع و أكثر فعالية و أبعد عن التجريد التي تأتي به اللغة " . ترسيخ الأساسيات و مفاهيم اللغة لا يأتي اعتباطا , فبعض المفاهيم لا يحتاج شرحها إلا بضع دقائق بالعفل ,.و لكن استيعابها و هضمها من طرفنا يتم على طول مسارنا و أثناء و بعد تطبيقاتنا العملية لها . لذلك فإن أفضل طريقة لإكتسابها هي بممارستها و تطبيقها و مجددا الصبر معها . فقد يحدث أن لا تستوعب بعض الأفكار أو أن تستوعبها جزئيا الان أو خلال تعلمك للأساسيات , ثم يدعوك موقف ما إلى استذكارها و إستيضاحها . كما أن مدربي الأكاديمية في خدمتك في أي لحظة , و على طول مسارك التعليمي في الدورة . و لذلك لا تتردد بشأن السؤال في القسم المخصص لتعليقات الطلبة أسفل كل فيديو حول أي مفهوم أو فكرة أو شيفرة يصعب فهمها لديك , و سيعمل المدربون على إيضاح الفكرة لك و تبسيطها . من شأن هذا أن يجعلك تطور من نفسك في أول خطوة من حل المشكلات و هي " وصفها " و من جهة أخرى سيبسط مناقشة الفكرة و الأخذ و الرد بشأنها فهمها و إيضاحها و إبعاد كل صعوبة عنها .

يحتمل أن ذلك بسبب طريقة قراءة معرف المقالة و الفئة من الرابط من الواجهة الخلفية . خصوصا و أنك ذكرت أنك تقوم بإستعمال $_GET لجلب ذلك . و كأن الأمر على هاته الشاكلة : $targetCategory = $_GET['category']; # جلب الفئة المستهدفة من الرابط ثم كتابة إستعلام لجلب المقالات ذات نفس الفئة : $query = 'SELECT * FROM articles WHERE category_id=' . $targetCategory; ما الذي يحدث هنا ؟ في حالة غياب الفئة => لن يتم إعادة أي نتائج من الإستعلام => بالتالي فإنه في حالة عدم توفير معرف للمقالة في الرابط فإنه لن يتم إظهار أي مواضيع ذات صلة , و في الأغلب هذا الذي حدث معك. لا يقترح أي حل للمشكلة سوى إعادة طريقة عرض الروابط بالطريقة القديمة , فهذا هو السبيل الوحيد للتواصل بين الواجهة الأمامية و الواجهة الخلفية . و إلا فإنه لن يتم الوصول إلى ما تقدمه الواجهة الأمامية من طرف الواجهة الخلفية لذات التطبيق . إن لم تمتلك أي خبرة تقنية , يمكنك الإستعانة بمبرمج ما لتعديل طريقة القراءة وفق ما هو أنسب لك , وفق ما يلبي حاجتك .

و عليكم السلام , هلا قمت بالتفصيل أكثر فيما تقصده بـ "تصغير رابط المواضيع بالموقع بإستخدام ملف htaccess. " ؟ كما أن مشكلتك غير واضحة جيدا , يرجى التفصيل أكثر

لنقم بإقتباس التعريفين التالين من ويكي حسوب كالتالي : و لنفترض أن حجم حاوية ما لدينا هو 1000 بكسل . هاته الحاوية تحوي 4 عناصر . قمنا بتحديد flex-basis أو أساس مرن لكل عنصر بـ 200 بكسل . سيجعل هذا العناصر تظهر كالتالي : كل من العناصر الأربع سيمتلك عرضا 200 بكسل .بالإضافة إلى مساحة إضافية متبقية 200 بكسل بعد توزيع العناصر . إذا قمنا الان بإعطاء العنصر الثاني flex-grow أو نمو مرن بمقدار 2 (أي تعويضا لعنصرين flex) ، فسيشغل هذا العنصر الثاني ضعف المساحة المتبقية عن العناصر الأخرى و سيأخذ 200 بكسل إضافية , و سيظهر و كأنه يتمدد على باقي العناصر . لاحظ نمذجة للعملية : و بالتالي ،فإنه من أجل استخدام flex-grow لعنصر ما ، يجب أولاً تعيين flex-basis لينطلق منه الـ flex-grow فيعتبره مرجعا و معيارا يحدد معدل التمدد من عليه , فإن حددنا أساسا بـ 100 بكسل و أعطينا قيمة نمو بـ 3 , فسيكون عنصر الـ flex هذا معوضا لـ 3 من قيمة الأساس أي 300 بكسل . و لتتذكر الأمر على هذا النحو : flex-basis : ترجمة لـ أساس مرن . flex-grow : ترجمة لـ نمو مرن . و لتحديد هذا النمو المرن لن نحتاج إلا لمعرفة ما هو المقدار الذي سينمو به عنصر عن باقي العناصر الأخرى , و عليه فإن : flex-grow تتطلب flex-basis . يمكنك الإطلاع على توثيق كل من الخاصيتين في ويكي حسوب كالتالي : flex-basis . flex-grow .

و عليكم السلام . قبل التعرض للقيم التي تأخذها الخاصية ينبغي أولا معرفة ما الذي تقوم به الخاصية , فالخاصية tranfrom-style أو نمط التحويل تحدد ما إذا كانت العناصر الفرعية أو الأبناء لعنصر ما موضوعة في مساحة ثلاثية الأبعاد أو إذا تم وضعها في مستوى العنصر الأب نفسه . أي أن الخاصية ممكن لها أن تأخذ أحد القيمتين : flat : يعني هذا أن العناصر الأبناء لعنصر ما يمتلك هاته الخاصية سيتم وضعها في نفس مستوى العنصر . preserve-3d : ترجمة للـحفاظ على البعد الثلاثي , و تجعل هاته القيمة الأبناء موضوعة في مساحة ثلاثية الأبعاد خاصة بها . و لإتضاح الفرق جيدا لاحظ الفرق بين الصورتين : الصورة رقم 1 : الصورة رقم 2 : لاحظ في كلتا الصورة أن العنصر الأب parent باللون البرتقالي يمتلك تحويلا معينا يعطيه الإنحناءة ثلاثية الأبعاد التي هو عليها , و مثل ما هو الحال مع محاور ذات العنصر , أي أن المحاور أيضا أعيد تعيينها بعد تطبيق التحويل الذي عليه . في الصورة الأولى : نلاحظ إنتماء العنصر الابن باللون الزهري إلى مستوى عنصر الأب , أي أن العنصر يظهر بشكل وكأنه مواز له , و لكنه في الحقيقة على ذات المستوى , كأن الأمر يجرد هكذا : في الصورة الثانية : نلاحظ تداخل العنصر الاابن باللون الزهري مع العنصر الأب , يظهر ذلك و كأن كل منهما مرسوم ومعبر عنه في مستوى خاص به , هذا المستوى هو مساحة ثلاثية الأبعاد خاصة به . و كأن الأمر هكذا : ففي الأولى : العناصر الأبناء للعنصر الحالي ستكون مسطحةً (flattened) في مستوى العنصر الأب . أي أن العنصر الأب يمتلك القيمة flat في خاصية نمط العنصر . و في الثانية : العناصر الأبناء للعنصر الحالي ستكون موجودةً في الفضاء ثلاثي الأبعاد الخاص بها . أي أن العنصر الأب يمتلك القيمة preserve-3d في خاصية نمط التحويل . و هو ما سؤالك حوله بالضبط . يمكن تلخيص قواعد الـ css لكل من المثالين كالتالي : صورة 1 : transform-style: flat; صورة 2 : transform-style: preserve-3d; تعرف أكثر على الخاصية transform-style من هنا . كما يمكنك الإطلاع على المثال الذي تم طرحه و التلاعب بقيم الخاصية من هنا .

يمكنك تشغيل الأمر التالي مباشرة : /opt/lampp/lampp start أو عن طريق sudo كالتالي : sudo /opt/lampp/lampp start ستلاحظ مجموعة تعليمات تخبرك بتمام تشغيله كالتالي : Starting XAMPP for Linux 1.5.3a... XAMPP: Starting Apache with SSL (and PHP5)... XAMPP: Starting MySQL... XAMPP: Starting ProFTPD... XAMPP for Linux started. ثم سيمكنك التصفح إلى : http://localhost بشكل عادي أو : https://localhost في حالة تشغيل دعم ssl أيضا . و لإيقافه لن تحتاج إلا لتشغيل نفس الأمر مرفقا بالتعليمة stop بدل start : sudo /opt/lampp/lampp stop بعض الأوامر الأخرى التي قد تحتاج لها في نفس الإطار : sudo /opt/lampp/lampp restart # إعادة التشغيل sudo /opt/lampp/lampp startapache # تشغيل خادم أباتشي فقط sudo /opt/lampp/lampp stopapache # إيقاف تشغيل خادم أباتشي فقط sudo /opt/lampp/lampp startssl # تشغيل دعم أس أس ال من قبل خادم اباتشي sudo /opt/lampp/lampp stopssl # إيقاف تشغيل دعم أس أس ال من قبل خادم اباتشي sudo /opt/lampp/lampp startmysql # تشغيل قواعد بيانات مايسكول sudo /opt/lampp/lampp stopmysql #إيقاف تشغيل قواعد بيانات مايسكول sudo /opt/lampp/lampp startftp # ProFTP تشغيل خدمة sudo /opt/lampp/lampp stopftp # ProFTPإيقاف تشغيل خدمة sudo /opt/lampp/lampp security # عمل اختبار تحقق سريع

و عليكم السلام و رحمة الله لا أظن أن يجب عليك تعلم إحداها فقط دون الأخرى , بل كلاهما . و هذا لأن لكل منها مجاله التخصصي و إستعمالاته و حاجته التي دعت إلى إنشاءه من الأساس , فالمقارنة بينهما غير منطقية . و لنأخذ كل منهما على حدة كالتالي : يستخدم Ajax بروتوكول HTTP ويمكنه إرسال طلبات باستخدام طرق POST و GET بين العميل والخادم. WebSocket هو بروتوكول اتصال بين العميل والخادم ، وهو يختلف عن HTTP . ففي Ajax ، عندما ترسل طلبًا ، يرسل الخادم استجابة لهذا الطلب ويتم إنهاء الاتصال , و هذا ما يجعله مناسبا لإستعمالات من مثل : التواصل مع واجهات تطبيق برمجية . أي أنه يسمح لتطبيق ما ,من جانب العميل, بطلب الوصول إلى مورد من جانب الخادم (مثلا : طلب صفحة أو صورة أو ملف أو بيانات) . في حين أن باستخدام WebSockets عند إنشاء اتصال بالخادم ، يمكنك التواصل بقدر ما تريد بين العميل والخادم والحفاظ على الاتصال نشطًا في كل لحظة , و هذا يجعله مناسبا للإستعمالات من مثل : تلقي إشعارات الوقت الفعلي أو الدردشة الحية , مثل الإشعار الذي تلقيته بشأن إجابة عن سؤالك هذا . يمكن تلخيص الأمر بشكل بسيط كالتالي : ما وراء الـ AJAX يعتمد إتصالا يتم إغلاقه مباشرة بعد الرد . ما وراء الـ WebSocket يعتمد إتصالا متواصلا . أمثلة توضيحية : يحتاج العميل " أحمد " تفحص صورة من على الخادم , فيقوم بإرسال طلب GET إلى الخادم . يستقبل الخادم الطلب و يقوم بإعادة رد برابط الصورة ليقوم أحمد برؤيتها , و ينتهي الإتصال و يتوقف الخادم عن تبادل أية بيانات بينه و بين أحمد , و سيحتاج أحمد اتصالا جديدا كل مرة يريد فيها طلب شيء من على الخادم . الان , العميل " أحمد " على موقع دردشة , ينتظر أي رسائل تصله . في مقابل أن العميل " عماد " يريد مراسلة " أحمد " . يقوم أحمد بإنشاء إتصال عن طريق بروتوكول ويب سوكيت بينه و بين الخادم , و ما إن وصلت أي رسائل جديدة لأحمد للخادم سيتم تنبيهه فورا . بعد أن يكتب عماد الرسالة و يرسلها , سيلتقط الخادم طلبه و يخزن الرسالة و يقوم فورا بتنبيه أحمد بذلك , فيكتب ردا و هكذا . أي أن من غير المعقول أن يشغل دور أحد الثاني , فلكل منهما منطقه الذي يتعامل به , فكل إستعمال لأحدهما في مجاله ميزة , و أي إستعمال له في غير تخصصه و مجاله عيب و هكذا . أما كاقتراح و تفضيل , فأفضل أن تتعلم Ajax أولا , كونه ما ستحتاج إليه طوال مسارك . ثم في وقت لاحق , قد تدعوك الحاجة إلى تعلم websocket لتحقيق أغراض أو حالات إستعمال معينة . و هو في الغالب ما كان مسار أي مطور . يمكنك تصفح إجابات مختلفة لتعاريف حول ما هو الـ websocket و لما قد نحتاجه هنا . كما قد تحتاج الإطلاع على كيفية التعامل مع ajax في الـ jQuery هنا .

لاحظ أنه لا يوجد لديك فواصل منقوطة في نهايات العديد من الأسطر : السطرين برقم 0 و 1 في بداية النموذج الثاني . السطر برقم 8 في نهاية النموذج الأول . الأسطر برقم 0 و 9 في بداية النموذج الأول . قد أدى هذا إلى تعطيل قراءة السكربت كاملا , و لو قمت بتفحص شاشة الـ console ستجد رسالة تخبرك بما يحدث كالتالي : SyntaxError: missing ; before statement أو : SyntaxError: Unexpected 'document' كما أنه قد يوجد لديك مشكل بتحديد العنصر بالصنف : Applicant في السطر 0 في بداية النموذج الثاني كالتالي : document.getElementByClassName('Applicant 2'); في حين أن العنصر يتوفر كالتالي : <div class="lineheightExtra"> Applicant 2 </div> فها أنت تحاول تحديد العنصر التالي دون توظيف إسم صنفه على نحو صحيح , فالمفترض أن يكون هو ما هو كالتالي : document.getElementByClassName('lineheightExtra'); و ذلك حتى يتم تحديده بشكل صحيح .

أفضل إستعمال مكتبة الجيكيوري DataTable لذلك فهي توفر وصولا أبسط لمختلف الصيغ التي نحتاج التصدير إليها . يتم تضمين ملف الجافاسكربت الخاص بها كالتالي : <script src="https://code.jquery.com/jquery-3.5.1.js"></script> <script src="//cdn.datatables.net/1.11.2/js/jquery.dataTables.min.js"></script> <script src="https://cdn.datatables.net/buttons/2.0.0/js/dataTables.buttons.min.js"></script> ثم ملف التنسيقات الخاص بها : <link rel="stylesheet" href="//cdn.datatables.net/1.11.2/css/jquery.dataTables.min.css" /> <link rel="stylesheet" href="https://cdn.datatables.net/buttons/2.0.0/css/buttons.dataTables.min.css" /> و أخيرا تهيئة المكتبة على جدول معين , مضافا إليها خيارات توفير أزرار التصدير : $(document).ready( function () { $('#myTable').DataTable({ dom: 'Bfrtip', buttons: [ 'excel' ] }); } ); ستلاحظ ظهور زر تصدير أعلى الجدول , يمكنك الضغط على excel للتحصل على جدولك مصدرا بصيغة ملف excel , و سيتم ذلك على الفور .

تكاد تكون أغلب هاته الوظائف ذات أسماء دلالية تدل على وظيفتها , مثلها مثل ملف init.js . فالدالة أو الوظيفة الأولى Ready ترجمة لجاهز : تعبر عن الإستدعاء بعد جهوزية الصفحة , و تحمل مجموع الشيفرات التي يتم إستدعاءها عند الحدث ready , و يتم هذا الحدث في اللحظة التي تكون قد حملت فيها الوثيقة . و الدالة أو الوظيفة الثانية تحمل مجموع الشيفرات التي يتم إستدعاءها عند الحدث load بالنسبة للنافذة , و يخص هذا الحدث تلك اللحظة التي تكون قد حُمّلت فيها كامل الموارد الخارجيّة مثل : روابط ملفات خارجية cdn أو صور . وبذلك تكون التنسيقات قد طُبّقت، ومقاسات الصور عُلمت، وما إلى ذلك . أما الوظيفة المعلقة بإسم Full Height function فتقوم هاته الدالة في الغالب بضبط مقاسات إرتفاع الحاويات و العناصر حتى تأخذ كامل الإرتفاع , مثل عنصر القائمة الجانبية. الوظيفة droopy , قد لا يدل إسمها عليها في الغالب. يلحظ أنها تحوي مجموع الشيفرات التي يتم فيها إضافة الأحداث إلى عناصر , و بعض الأسطر الأخرى التي يتم فيها تهيئة إضافات جيكويري مثل : Tooltip Popover Accordion js Slimscroll الوظيفة chat app تقوم في الغالب بضبط بعض الإعدادت الخاصة بمربع الدردشة , كما أنها تقوم بإضافة بعض الأحداث المتعلقة بذات العنصر . الوظيفة resize تشمل مجموع الشيفرات التي يتم إستدعاءها عند محاولة إعادة ضبط حجم الشاشة . من الصعب جدا تحديد ما يقوم به كل سطر من الشيفرة دون التوغل فيها بشكل كبير جدا , كما أن الملف كغيره من ملفات الجافاسكربت التي تحمل مجموع شيفرات معينة , و بالتالي فإن الوظائف التي يحويها الملف ليست أكثر من وظائف جافاسكربت عادية . فحاجة مبرمج الموقع إلى تنظيم عمله و تهيئة الموقع بشكل أنظف و أكثر تنظيما دعته إلى إنشاء كل الوظائف , التي من شأنها تهيئة : عنصر , مكتبة أو حدث , في ملف منفصل .

هو بداية ليس أكثر من ملف جافاسكربت عادي , و في الغالب الملفات بالإختصار الدلالي init هي إختصار للكلمة initialize و التي تعني بدء أو تهيئة بالعربية . و دليله هو احتواءه على ما هو لازم لتهئية مجموعة الوظائف أو الموقع و تفاعليته مثل الذي لديك . لذلك نجده من يضعه في جافاسكربت و يضم به وضائف من مثل : إضافة أحداث و تفاعليات إلى عناصر الـ DOM أو تهيئة و إعداد أي مكتبات أو إضافات لإستعمالها . وهو نفس ما يقوم به صاحب الموقع بنفس الملف , لاحظ قطعة من سلسلة عمليات إضافة الأحداث : /*Sidebar Navigation*/ $(document).on('click', '#toggle_nav_btn,#open_right_sidebar,#setting_panel_btn', function (e) { $(".dropdown.open > .dropdown-toggle").dropdown("toggle"); return false; }); $(document).on('click', '#toggle_nav_btn', function (e) { $wrapper.removeClass('open-right-sidebar open-setting-panel').toggleClass('slide-nav-toggle'); return false; }); $(document).on('click', '#open_right_sidebar', function (e) { $wrapper.toggleClass('open-right-sidebar').removeClass('open-setting-panel'); return false; }); $(document).on('click', '.product-carousel .owl-nav', function (e) { return false; }); $(document).on('click', 'body', function (e) { if ($(e.target).closest('.fixed-sidebar-right,.setting-panel').length > 0) { return; } $('body > .wrapper').removeClass('open-right-sidebar open-setting-panel'); return; }); $(document).on('show.bs.dropdown', '.nav.navbar-right.top-nav .dropdown', function (e) { $wrapper.removeClass('open-right-sidebar open-setting-panel'); return; }); $(document).on('click', '#setting_panel_btn', function (e) { $wrapper.toggleClass('open-setting-panel').removeClass('open-right-sidebar'); return false; }); $(document).on('click', '#toggle_mobile_nav', function (e) { $wrapper.toggleClass('mobile-nav-open').removeClass('open-right-sidebar'); return; }); لاحظ تهيئة العديد من إضافات الجيكويري و البوتستراب للإستعمال : /*Counter Animation*/ var counterAnim = $('.counter-anim'); if (counterAnim.length > 0) { counterAnim.counterUp({ delay: 10, time: 1000 }); } /*Tooltip*/ if ($('[data-toggle="tooltip"]').length > 0) $('[data-toggle="tooltip"]').tooltip(); /*Popover*/ if ($('[data-toggle="popover"]').length > 0) $('[data-toggle="popover"]').popover() أي أنه ليس أكثر من ملف بإسم دلالي لتنظيم عملية سير الموقع و تهيئة اللازم لسيرها بشكلها الصحيح . و بالتالي فإن ما وصفته بالمكتبات : ليس كذلك و إنما أشبه بالوظائف أو العمليات المنفصلة , و تعليقها أعلى الملف ليس أكثر من فهرسة لمحتويات الملف , فمثلا : الوظيفة Ready تشمل مجموع الشيفرات التي يتم إستدعاءها بعد تحميل الوثيقة , و هي نفسها تستدعي الوظيفة droopy . لا أبدا , فالملف يستعمل فقط جيكويري و سياق لتهئية الموقع , المكتبات , الإضافات و الأحداث . لا , فذلك غير منطقي أبدا . و لكل ملف حاجته و دوره و لا علاقة لأحدهما بالثاني , فـ package.json هو مستند JSON ، يعتمد عليه مدير حزم الجافاسكربت npm لإدارة الحزم و القراءة من عليها . أما ملف init.js فهو مجرد ملف كغيره من ملفات الجافاسكربت , يحمل شيفرات جافاسكربت عادية . الشيء الوحيد الذي يجعل اسمه دالا عليه هو أن هاته الشيفرات تستعمل بغرض التهيئة و التحضير .

المستخدم الذي قام بالتلاعب بقيمة المتغير المؤثرة في شروط عرض مكونات معينة لن يكون تعديل شيفرة المراقبة و إعادة التحميل مشكلة بالنسبة له . كما أن هاته الحالات خاصة جدا , فعوام المستخدمين لا يفكرون بنفس الطريقة . و حتى إن كان و تم الوصول لذلك بأية طريقة كانت , لن يكون من عرض قالب فارغ جدوى من الأساس . أي أن الأهم من كل ذلك : مصادقة طلبات جلب البيانات قبل عرضها , و يكون كل هذا في الواجهة الخلفية بعيدا عن المستخدم . كما أن هذا لا يمنعك من ضبط طريقة التصفح و منع عوام المستخدمين من الوصول إلى صفحات ليست لهم صلاحية الوصول إلى البيانات التي تعرض بهاته المكونات , و يكون ذلك بالتوجيه إلى صفحات عامة أو قابلة للوصول من أي كان في حالة إرسال طلب من مكون خاص لا يمكن لمستخدم عام تصفحه .