لقد رأينا بالفعل استخدام عمليات الحصول على HTTP في التدريبين السابقين،
حيث سنتمكن من الذهاب وجلب البيانات من
الخادم واستخدامها في تطبيق Angular الخاص بنا.
ولكن هناك حالات حيث تريد أن تكون قادرًا على نشر بيانات جديدة
إلى الخادم، أو تعديل البيانات الموجودة على الخادم،
أو حتى حذف البيانات.
لذلك هذا هو المكان الذي
تمكننا فيه المشاركة، ووضع، وحذف عمليات HTTP من تنفيذ ذلك.
في هذا التمرين، سننظر في استخدام عملية وضع من
عميل HTTP التي تمكننا من تعديل طبق موجود على جانب الخادم.
الآن، لماذا يجب أن نفعل ذلك؟
رأيت أنه في أحد التمارين السابقة،
سمحنا للمستخدم بنشر تعليق على طبق،
ثم تمكنا من إدراج التعليق في كائن الطبق.
الآن، نريد أن تستمر هذه المعلومات الطبق على الخادم،
الطبق المعدل إلى الخادم.
هذا هو المكان الذي يأتي فيه استخدام عملية HTTP PUT لإنقاذنا.
لذلك، باستخدام عملية هتب بوت،
ونحن قادرون على إرسال طبق تعديل مرة أخرى إلى الخادم ثم تعديل
معلومات طبق الموجودة على الخادم بحيث
التعليق المضافة حديثا يمكن أن تستمر على جانب الخادم.
وبالتالي، عندما يتم جلب المعلومات في وقت لاحق،
سيكون التعليق المضافة حديثا هناك كجزء من معلومات طبق.
لذلك، هذا هو ما سوف نستكشفه في هذا التمرين،
حيث سننظر في حفظ التغييرات على الخادم.
إذاً، كيف يمكننا فعل هذا؟
دعونا استكشاف هذا في التمرين.
لتمكيننا من حفظ التغييرات على الطبق إلى الخادم،
اسمحوا لي أن أعرض طريقة جديدة في خدمة الطبق هنا.
الآن، سنضيف طريقة جديدة تسمى PutDish إلى الخادم.
لذا، كيف تعمل طريقة بوتديش؟
لذا، اسمحوا لي أن أعرض طريقة PutDish هنا التي تتلقى بوضوح الطبق المعدل
كمعلمة لها ومن ثم سيعود ملاحظة من نوع طبق.
لذلك، سيؤدي ذلك إلى إرجاع الطبق الذي تم وضعه في جانب الخادم.
الآن، بمجرد تعديل الطبق على جانب الخادم،
سيتم إرسال معلومات الطبق المعدلة مرة أخرى من قبل الخادم،
ومن ثم سيتم تسليم هذا الطبق المعدل
مرة أخرى إلى العميل بحيث يمكن للعميل دمج ذلك،
ومن ثم تحديث واجهة المستخدم لتعكس التغيير إلى الطبق.
الآن، من الواضح أننا لا نريد أن تعكس التغيير
إلى واجهة المستخدم حتى يتم حفظ معلومات طبق على جانب الخادم.
لذا، هذا هو المكان الذي سنستخدم فيه
طريقة PutDish التي نقدمها في خدمة الطبق.
لذلك، كيف يمكننا تصميم طريقة بوتديش؟
لذا، فإن أول شيء نحتاج إلى القيام به هو إعداد بعض خيارات HTTP بحيث نبلغ
الخادم بما
يتم إرساله في الرسالة هنا.
لذلك، سنقوم بإعداد بعض معلومات الرؤوس هنا.
لذلك، بالنسبة للرؤوس، سنقوم بإعداد HttpHeaders
جديدة هنا، وفي HttpHeaders الجديد،
دعنا نقوم بإعداد الرأس
كنوع المحتوى من نوع التطبيق JSON.
لذلك، نحن نحدد إلى خادمنا أن رسالة الطلب
الواردة تحتوي على المعلومات في
شكل كائن json في نص رسالة الطلب الواردة.
لذلك، فإن الخادم تكون قادرة
على استخراج معلومات طبق من نص الرسالة، تحليلها،
ومن ثم تكون قادرة على الاستمرار في طبق تعديل إلى الخادم،
ومن ثم إرسال معلومات طبق المحدثة من جانب الخادم.
الآن، بمجرد إعداد الخيارات هنا،
سنستخدم
عميل HTTP ثم نقوم
بوضع يحمل الطبق بوضوح في نص الرسالة،
ثم سنقوم بتحديد baseurl+أطباق و+dish.id
، لذلك، هذا هو عنوان URL الذي نرسل عملية وضع لذلك،
لذلك، من معرفة REST API الخاصة بك،
سترى لماذا نقوم بعملية وضع إلى نقطة النهاية هذه.
ثم المعلمة الثانية هي الطبق نفسه الذي
نتلقاه كمعلمة واردة إلى طريقة PutDish،
ثم المعلمة الثالثة هي HttPoptions التي قمنا بإعدادها منذ فترة قصيرة.
ثم، بمجرد الحصول على ذلك،
سنكون قادرين على توجيه
أي خطأ إلى طريقة HandleError لدينا سماع، هذا كل شيء.
لذا، فإن هذه المكالمة إلى وضع على جانب الخادم ستمكن
معلومات الطبق لتكون مستمرة على جانب الخادم ومن ثم
سيقوم الخادم بإرجاع معلومات الطبق المحدثة إلينا،
ومن ثم سنعود ذلك مرة أخرى إلى المكون الخاص بنا
حيث يمكن للمكون ثم استخدام ذلك لتقديم معلومات طبق محدثة.
لذلك، هذا هو التعديل الذي نقوم به لخدمة الطبق.
الآن، انتقل إلى مكون dishdetail،
في مكون dishdetail،
دعني أعرض متغير آخر هنا
يسمى dishcopy الذي سيحتفظ
بنسخة من الطبق المعدل حتى يتم نشره على الخادم.
لذلك، سوف تحتوي على طبق معدلة.
لذلك، الذهاب إلى المعلمات الطريق هنا.
لذلك، ما نقوم به هو في أي وقت يتم تعديل معلومات طبق هنا في معلمات الطريق،
أيضا جنبا إلى جنب مع حفظ معلومات الطبق إلى هذا. dish،
وسوف أيضا حفظ نسخة إلى طبق
أيضا بحيث كل من طبق و
dishcopy تحتوي على نسخة طبق الأصل من نفس الطبق هنا.
لذلك، هذا هو التعديل الذي سنقوم به هنا.
الآن، في طريقة onSubmit،
لذلك لدينا هنا طريقة onSubmit هنا،
حيث نقوم بتعديل الكائن هنا.
لذلك، هنا، لاحظت أننا كنا في الأصل دفع التعليق إلى كائن طبق هنا،
بدلا من ذلك، ونحن سوف تدفع الآن التعليق إلى كائن ديسكوبي.
السبب في أنني أفعل هذا هو أنني أريد أولا تعديل كائن ديسكوبي،
ثم أريد أن نشر ذلك إلى الخادم،
وبعد ذلك عندما رد الخادم مرة أخرى مع
معلومات الطبق المعدلة إلى جانب الخادم،
ثم سوف تستمر هذه المعلومات في طبق هنا.
لذلك، بعد القيام بالتنظير هنا،
ثم سنقول هذا.DishService.Putdish،
وبعد ذلك سنقوم بتوريد إلى
بوتديش ديكوبي كمعلمة
لأن ديكوبي يحتوي على نسخة معدلة من الطبق هنا.
لذلك، سوف نقول ديسكوبي،
وبعد ذلك عندما نتلقى الرد من جانب الخادم لذلك،
في الاشتراك، ونحن سوف نقول طبق والحق هناك،
ونحن سوف التعامل مع طبق واردة هنا.
لذلك، هنا، سوف نقول الاشتراك طبق وبعد ذلك سنقول،
هذا. طبق يساوي طبق هنا،
ومن أجل اكتمال،
وسوف تستمر أيضا نفس المعلومات في طبق هنا.
الآن، إذا كان هناك خطأ،
فسيتعين عليك HandleError.
لذلك، إلى
handleError، سنقول، إرميسي، وبعد ذلك في هذه المرحلة،
سنقوم بتعيين أن هذا.dish إلى نول،
ومن ثم هذا الطبق أيضا إلى نول لأنه في الوقت الحالي الطبق غير صالح،
وبعد ذلك سنقول هذا.errmess هو
أي خطأ، هذا كل شيء.
هذا هو التعديل الذي سنقوم به على طريقة onSubmit.
لذلك، باستخدام this.DishService.Putdish الأسلوب،
ونحن نرسل في
طبق المحدثة هنا،
وليس طبق هنا، وبعد ذلك عندما رد الخادم مرة أخرى لنا مع طبق تعديل
، في هذه المرحلة، ونحن سوف تستمر المعلومات في هذا.
بحيث في هذه المرحلة،
سيتم تحديث واجهة المستخدم لدينا مع الإصدار المحدث إلى طبق،
وأنا أيضا استمرار نفس المعلومات إلى طبق،
وبعد ذلك إذا واجهت خطأ،
ثم سأقوم بتعيين هذا. dish إلى فارغة وهذا.discopy إلى فارغة
ثم قم بإعداد رسالة الخطأ هنا بشكل مناسب.
إذن هذا كل شيء دعونا حفظ التغييرات ثم انتقل
ونلقي نظرة على تطبيقنا في المتصفح.
حفظ التغييرات، دعونا نعود إلى المتصفح.
انتقل إلى المتصفح، دعونا نذهب الآن إلى القائمة ثم انتقل إلى طبق معين هنا.
بالنسبة للطبق المحدد،
دعنا ننشر تعليقًا هنا.
لذلك، اسمحوا لي أن نشر تعليق هنا مع تصنيف هنا.
لذلك، كما ترى، كما يصبح التعليق صالحًا،
تظهر معاينة التعليق هناك.
دعونا الآن تقديم هذا التعليق.
عند إرسال التعليق،
سترى على الفور أن التعليق قد تم نشره للتو في قائمتي من الأطباق.
الآن، في وقت سابق، إذا قمت بتحديث طريقة العرض،
فسيختفي هذا التعليق.
اسمحوا لي الآن تحديث العرض وبعد ذلك ستلاحظ أن التعليق
سيظل جزءًا من قائمة الأطباق هنا.
لذلك، كما ترون هنا،
لا يزال التعليق موجودًا هنا.
لتظهر لك أيضًا أن التعليق قد استمر بالفعل على جانب الخادم،
دعنا نذهب وننظر إلى سجل الخادم في المحطة الطرفية.
بالعودة إلى المحطات،
سنرى الآن أنه في سجل المحطة،
سترى طريقة PU/disanes/0 جديدة.
لذلك، وهذا يدل على أن طبق تعديل
قد استمر مرة أخرى إلى الخادم هناك الحق وبعد ذلك،
بالطبع حصلنا على الأطباق عن طريق تحديث
واجهة المستخدم ولهذا السبب نحن
جلب معلومات الأطباق مرة أخرى من جانب الخادم.
لذلك، وهذا يدل على أننا قادرون
على استخدام عملية هتب بوت لمواصلة طبق تعديل إلى الخادم،
وبعد ذلك عندما نتلقى الطبق المحدث،
ونحن قادرون على تحديث واجهة المستخدم في المقابل.
مع هذا، نكمل هذا التمرين.
هذا هو الوقت المناسب بالنسبة لك للقيام جيت الالتزام مع الرسالة،
وحفظ التغييرات على هذا الخادم.