سیگنال‌ها یک مکانیسم ارتباطی بین بخش‌های مختلف پروژه جنگو هستند که اجزا را قادر می‌سازد تا اعلان‌هایی را برای فعال کردن اقدامات در پاسخ به رویدادها ارسال کنند. در این آموزش، ما اصول اولیه سیگنال‌های جنگو را تحلیل می‌کنیم، به این موضوع می‌پردازیم که چگونه آن‌ها نگهداری از پایگاه کد مدولار و مقیاس‌پذیر را امکان‌پذیر می‌کنند، برخی از سیگنال‌های داخلی را تحلیل می‌کنیم، و چگونگی تعریف سیگنال‌های سفارشی را تحلیل می‌کنیم.

اغلب اوقات، یک پروژه جنگو بیش از یک برنامه دارد. به عنوان مثال، در یک پروژه تجارت الکترونیک ممکن است یک برنامه برای مدیریت کاربر، یک برنامه سفارشات، یک برنامه محصولات، یک برنامه پرداخت و غیره داشته باشیم. به این ترتیب، هر برنامه صرفاً بر روی یک عملکرد خاص متمرکز خواهد شد.

اما در پایان روز، همه این برنامه ها باید به طور هماهنگ کار کنند تا پروژه تجارت الکترونیک یکپارچه شود. ممکن است یک یا چند برنامه علاقه مند به دانستن زمان وقوع یک رویداد خاص در برنامه دیگری باشند. به عنوان مثال، برنامه محصول ممکن است علاقه مند باشد که بداند کاربر چه زمانی سفارش را تأیید می کند - که به برنامه محصول امکان می دهد موجودی را به روز کند.

اما از آنجایی که دو اپلیکیشن مجزا هستند، اپلیکیشن محصول چگونه متوجه می شود که کاربر سفارشی را ثبت می کند؟ برای حل این مشکل، چارچوب جنگو از یک توزیع کننده سیگنال استفاده می کند. با استفاده از این چارچوب، برنامه سفارش‌ها پس از ذخیره شدن سفارش، سیگنالی ارسال می‌کند و برنامه محصولات پس از دریافت این اطلاعات، موجودی کالا را به‌روزرسانی می‌کند.

پس چارچوب سیگنالینگ اجازه می دهد تا برنامه های کاربردی در یک پروژه جدا شوند و آنها را قادر می سازد بدون وابستگی شدید با یکدیگر ارتباط برقرار کنند.

خوراکی های کلیدی

درک سیگنال ها

سیگنال‌ها در جنگو یک سیستم اعلان هستند که به فرستنده‌های خاصی اجازه می‌دهد تا هنگام انجام اقدامات خاصی، مجموعه‌ای از گیرنده‌ها را مطلع کنند. آن‌ها به برنامه‌های جداشده کمک می‌کنند تا زمانی که اقدامات یا رویدادهای خاصی در جای دیگری از چارچوب اتفاق می‌افتد مطلع شوند. در زمینه مثال ما، برنامه سفارش‌ها پس از تأیید سفارش، سیگنالی را «ارسال» می‌کند، و از آنجایی که برنامه محصولات به این رویداد علاقه‌مند است، برای «دریافت» آن ثبت‌نام کرده است، و سپس مقداری طول می‌کشد. اقدام به هنگام دریافت

نحوه کار سیگنال ها در جنگو

سیگنال‌ها مشابه الگوی pub-sub کار می‌کنند - جایی که فرستنده سیگنال ناشر است و گیرنده سیگنال مشترک است. این بدان معناست که برای دریافت سیگنال، گیرنده باید برای دریافت سیگنال مشترک شده باشد (در این مورد ثبت نام کرده باشد).

فرستنده و گیرنده سیگنال

فرستنده سیگنال هر شی پایتون است که سیگنالی را منتشر می کند، در حالی که گیرنده هر تابع یا روش پایتون است که در پاسخ به سیگنال ارسال شده اجرا می شود. همچنین توجه به این نکته مهم است که برخی از سیگنال ها - به ویژه سیگنال های داخلی - همیشه ارسال می شوند، چه گیرنده ثبت شده وجود داشته باشد یا نه. در مثال ما، اپلیکیشن orders فرستنده سیگنال و اپلیکیشن محصولات گیرنده سیگنال خواهد بود.

راه اندازی یک پروژه جنگو

برای نشان دادن نحوه عملکرد سیگنال‌ها، اجازه دهید با دنبال کردن مراحل زیر، یک پروژه نمونه را پیاده‌سازی کنیم.

دایرکتوری پروژه را ایجاد کنید

 mkdir my_shop

این یک دایرکتوری به نام my_shop ایجاد می کند که پروژه تجارت الکترونیک را نگه می دارد.

یک محیط مجازی ایجاد و فعال کنید

یک محیط مجازی یک محیط پایتون ایزوله است که به ما اجازه می دهد تا وابستگی های یک پروژه را بدون تأثیرگذاری بر محیط جهانی پایتون نصب کنیم. این بدان معناست که ما می‌توانیم پروژه‌های مختلفی را در یک ماشین اجرا کنیم که هر کدام وابستگی‌های خاص خود را دارند و احتمالاً روی نسخه‌های مختلف جنگو اجرا می‌شوند.

برای ایجاد یک محیط مجازی، از بسته virtualenv استفاده می کنیم. این بخشی از کتابخانه استاندارد پایتون نیست، پس آن را با دستور زیر نصب کنید:

 pip install virtualenv

پس از نصب بسته، برای ایجاد یک محیط مجازی برای این پروژه، باید وارد دایرکتوری my_shop شویم:

 cd my_shop

با استفاده از دستور زیر یک محیط مجازی ایجاد کنید:

 virtualenv venv

دستور بالا یک محیط مجازی به نام venv ایجاد می کند. پس از ایجاد آن، باید آن را فعال کنیم تا از آن استفاده کنیم.

برای Linux/macOS:

 . venv/bin/activate

برای ویندوز:

 . venv \ Scripts \ activate

جنگو و سایر وابستگی ها را نصب کنید

هنگامی که محیط مجازی فعال است، می‌توانیم جنگو و سایر وابستگی‌های مورد نیاز پروژه را نصب کنیم، اما برای این نمایش فقط به جنگو نیاز داریم:

 pip install Django

ایجاد پروژه

پس از نصب موفقیت آمیز جنگو، یک پروژه ایجاد کنید و نام آن را my_shop شبیه به دارنده پروژه ای که در بالا ایجاد کردیم، بگذارید:

 django-admin startproject my_shop .

دستور بالا یک پروژه جنگو با نام my_shop ایجاد می کند. نقطه در انتها نشان می دهد که ما قصد داریم پروژه را بدون ایجاد دایرکتوری های اضافی در دایرکتوری فعلی ایجاد کنیم.

ایجاد برنامه های فردی

اکنون دو برنامه ایجاد خواهیم کرد - برنامه products و برنامه orders . ابتدا برنامه products را با فایل های پیش فرض برای هر برنامه جنگو ایجاد می کنیم:

 python manage.py startapp products

برنامه محصولات را به برنامه های نصب شده پروژه اضافه کنید، دایرکتوری my_shop را باز کنید، سپس به فایل settings.py بروید و به تنظیمات INSTALLED_APPS بروید و خط کد زیر را در پایین اضافه کنید:

 INSTALLED_APPS = [ 'products.apps.ProductsConfig' , ]

این تنظیم، برنامه products را در پروژه ثبت می‌کند و ما را قادر می‌سازد تا مهاجرت‌هایی را اجرا کنیم که جداول پایگاه داده را ایجاد می‌کنند.

سپس برنامه orders را ایجاد کنید:

 python manage.py startapp orders

همانطور که برای برنامه products انجام دادیم، برنامه orders را نیز به تنظیمات INSTALLED_APPS اضافه می کنیم. فایل settings.py را باز کنید و خط کد زیر را در پایین اضافه کنید:

 INSTALLED_APPS = [ 'orders.apps.OrdersConfig' , ]

تعریف مدل برای برنامه ها

این نمایش شامل تغییر و به‌روزرسانی برخی از مقادیر در پایگاه داده، برای نشان دادن برخی تغییرات وضعیت است که در نهایت منجر به وقوع برخی رویدادها می‌شود، و برای آن باید مدل‌هایی را برای این دو برنامه تعریف کنیم. بیایید ابتدا مدل های اپلیکیشن products را تعریف کنیم. برنامه products را باز کنید و به فایل models.py بروید و بلوک کد زیر را وارد کنید:

 from django . db import models class Product ( models . Model ) : name = models . CharField ( max_length = 100 ) description = models . TextField ( ) price = models . DecimalField ( max_digits = 10 , decimal_places = 2 ) quantity = models . PositiveIntegerField ( default = 0 ) def __str__ ( self ) : return self . name

کد بالا یک مدل محصول را تعریف می‌کند که با چند فیلد کاملاً توصیفی به جدول محصولات در پایگاه داده نگاشت می‌شود.

سپس مدل های orders را تعریف کنید. برنامه orders را باز کنید و کد زیر را در فایل models.py قرار دهید:

 from django . db import models from products . models import Product class Order ( models . Model ) : product = models . ForeignKey ( Product , on_delete = models . CASCADE ) quantity = models . PositiveIntegerField ( ) total_price = models . DecimalField ( max_digits = 10 , decimal_places = 2 , blank = True , null = True ) confirmed = models . BooleanField ( default = False ) def save ( self , * args , ** kwargs ) : self . total_price = self . product . price * self . quantity super ( ) . save ( * args , ** kwargs ) def __str__ ( self ) : return f" { self . quantity } x { self . product . name } "

پس از تعریف مدل ها، باید مهاجرت ها را اجرا کنیم. با این کار جداول در پایگاه داده ایجاد می شود. Django ORM از دستورات مدیریت پایگاه داده مختلفی استفاده می کند، اما در حال حاضر از دو مورد استفاده شده برای تهیه جداول پایگاه داده استفاده می کنیم.

تا این مرحله، ما پروژه را اجرا نکرده ایم تا آزمایش کنیم که آیا درست تنظیم شده است یا خیر. قبل از اجرای migrations برای ایجاد دو مدل جدید، اجازه دهید پروژه را با استفاده از دستور زیر اجرا کنیم:

 python manage.py runserver

دستور بالا سرور توسعه را روشن می کند و اگر همه چیز به درستی تنظیم شده باشد، باید خروجی مشابه زیر داشته باشیم:

 Watching for file changes with StatReloader Performing system checks .. . System check identified no issues ( 0 silenced ) . You have 18 unapplied migration ( s ) . Your project may not work properly until you apply the migrations for app ( s ) : admin, auth, contenttypes, sessions. Run 'python manage.py migrate' to apply them. January 15 , 2024 - 11 :22:19 Django version 5.0 .1, using settings 'sitepoint_django_signals_tutorial.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C.

اگر خروجی مشابهی داشته باشیم، به این معنی است که پروژه به درستی پیکربندی شده است و ما یک پروژه جنگو اولیه در حال اجرا داریم. اگر خطایی رخ داد، توصیه می‌کنم به انجمن بروید تا پیشنهاداتی در مورد نحوه برخورد با آنها دریافت کنید.

در حالی که هنوز در خروجی هستید، بیایید به خط چهارم که با "18 مهاجرت اعمال نشده" شروع می شود توجه کنیم. اگر بخواهیم از یک پایگاه داده برای پروژه جنگو خود استفاده کنیم، که یک چارچوب شامل باتری است، جنگو تعدادی جداول برای مدیریت ایجاد می کند، و این همان چیزی است که این هشدار درباره آن است. به این معنی است که ما جداول مدیریت جنگو را ایجاد نکرده ایم.

برای ایجاد آنها، دستور زیر را اجرا کنید:

 python manage.py migrate

اجرای این دستور تعداد زیادی جدول ایجاد می کند. اما جداول در کجا ایجاد می شوند؟ ما هنوز پایگاه داده ای را برای استفاده در پروژه خود راه اندازی نکرده ایم! جنگو با SQLite3 به صورت پیش‌فرض از پیش پیکربندی شده عرضه می‌شود. پس ، ما برای کار با SQLite نیازی به پیکربندی نداریم.

اکنون که جداول مدیریت جنگو ایجاد شده است، باید جداول را برای برنامه های products و orders ایجاد کنیم. برای انجام این کار، به دو مجموعه دستور نیاز داریم، و این فرمتی است که هر بار که می‌خواهیم یک جدول جدید برای مدل جدید تعریف شده ایجاد کنیم، دنبال می‌شود. اولین دستور تعریف کلاس مدل ما را به SQL مورد نیاز برای ایجاد جداول پایگاه داده تبدیل یا نگاشت می کند و دستور makemigrations است:

 python manage.py makemigrations

اجرای آن دستور بدون تعیین هیچ برنامه ای، مهاجرت برای همه برنامه ها ایجاد می کند. مورد بعدی اعمال مهاجرت ها است که در نهایت جداول را با استفاده از دستور زیر ایجاد می کند:

 python manage.py migrate

این دستور جداول دو برنامه ای را که در این نمونه برنامه داریم ایجاد می کند.

اصول اولیه سیگنال های جنگو

در این بخش، بیایید به اصول سیگنال های جنگو بپردازیم. ما مراحلی را که باید دنبال کنیم تا سیگنال‌هایی را که در یک برنامه کار می‌کنند دنبال کنیم، تحلیل می‌کنیم. ما این کار را با ایجاد تغییرات تدریجی در پروژه ای که به تازگی راه اندازی کرده ایم انجام خواهیم داد.

وارد کردن ماژول های لازم

برای دریافت سیگنال برای کار در پروژه ما، وارد کردن ماژول های مورد نیاز ضروری است. برای شروع، Signal و receiver از ماژول django.dispatch وارد می کنیم. کلاس Signal برای ایجاد یک نمونه سیگنال استفاده می شود - به خصوص اگر بخواهیم سیگنال های سفارشی ایجاد کنیم. در پروژه نمونه، در برنامه orders ، ما فقط کلاس Signal را وارد می کنیم، در حالی که ماژول receiver در برنامه products وارد می شود. ماژول receiver از دکوراتور receiver استفاده می کند که کنترل کننده سیگنال را به فرستنده سیگنال متصل می کند.

در حالی که ماژول django.dispatch به عنوان ماژول اصلی برای تعریف سیگنال های سفارشی عمل می کند، جنگو سیگنال های داخلی را ارائه می دهد که از طریق ماژول های دیگر قابل دسترسی هستند. ما آنها را با جزئیات بیشتری در بخش سیگنال های داخلی پوشش خواهیم داد.

با استفاده از پروژه نمونه، بیایید ببینیم چگونه می توانیم عملکرد سیگنال ها را اضافه کنیم. مستندات جنگو توصیه می کند که یک فایل signals.py ایجاد کنیم که حاوی تمام کدهای سیگنال ها باشد. در ریشه برنامه products و orders ، یک فایل ایجاد کنید و نام آن را signals.py بگذارید.

ایجاد یک نمونه سیگنال

در اپلیکیشن orders فایل signals.py را باز کرده و کد زیر را وارد کنید:

 from django . dispatch import Signal order_confirmed = Signal ( )

کد بالا یک سیگنال order_confirmed ایجاد می کند که با تأیید سفارش ارسال می شود، البته به صورت دستی.

اتصال سیگنال ها در apps.py

پس برای اینکه عملکرد ارسال و دریافت سیگنال در طول چرخه عمر برنامه در دسترس باشد، باید سیگنال‌ها را در فایل پیکربندی برنامه متصل کنیم. ما این کار را برای هر دو برنامه انجام خواهیم داد.

برنامه orders را باز کنید سپس به فایل apps.py بروید و کلاس OrdersConfig را با روش زیر به روز کنید:

 def ready ( self ) : import orders . signals

متد ready() read یک متد داخلی از کلاس AppConfig است که توسط کلاس‌های پیکربندی برنامه خاصی که ما با آن کار می‌کنیم گسترش می‌یابد. در این مورد خاص، OrdersConfig آن را گسترش می‌دهد، و از این رو روش‌هایی، از جمله ready() ، برای گسترش و لغو آن در دسترس هستند. پس ، در این مورد، نادیده گرفتن روش، سیگنال هایی را تنظیم می کند که زمانی که برنامه به طور کامل بارگذاری می شود، ارسال شود.

مرحله بعدی اتصال سیگنال ها در برنامه products است. آن را باز کنید و به فایل apps.py بروید و بلوک کد زیر را وارد کنید:

 def ready ( self ) : import products . signals

این گفت ن در هر دو برنامه تضمین می کند که سیگنال ها هنگام شروع چرخه پاسخ درخواست ارسال می شوند.

ایجاد یک فرستنده سیگنال

جنگو دو روش برای فعال کردن ارسال سیگنال ارائه می دهد. می توانیم از Signal.send() یا Signal.send_robust() استفاده کنیم. تفاوت آنها در این است که متد send() هیچ استثنایی را که توسط گیرندگان مطرح شده است را نمی گیرد.

برای ارسال سیگنال، روش به شکل زیر است:

 Signal . send ( sender , ** kwargs )

Signal تا حدودی یک مکان نگهدار به معنای سیگنال ارسال است - مانند order_confirmed.send() - در حالی که آرگومان sender می تواند برنامه ارسال سیگنال یا یک مدل یا بخشی دیگر از چارچوب باشد که می تواند سیگنال ارسال کند. فرستنده در مثال ما نمونه ای از سفارشی خواهد بود که به تازگی به عنوان sender=order تایید شده است.

بیایید نحوه استفاده از سیگنال order_confirmed را در برنامه نمونه خود ببینیم. از آنجایی که می‌خواهیم پس از تأیید سفارش، سیگنال را ارسال کنیم، در نمایی که پردازش سفارش را مدیریت می‌کند، در اینجاست که می‌خواهیم سیگنال را از زمانی که کاربر سفارش خود را تأیید کرد، ارسال کنیم. پس برنامه orders views.py را باز کنید و بلوک کد زیر را وارد کنید:

 from django . shortcuts import get_object_or_404 from django . http import HttpResponse from django . dispatch import receiver from orders . models import Order def confirm_order ( request , order_id ) : if request . method == 'POST' : order = get_object_or_404 ( Order , id = order_id ) order_confirmed . send ( sender = order ) return HttpResponse ( f"Order { order_id } confirmed successfully." ) else : return HttpResponse ( "Invalid request method. Use POST to confirm the order." )

اتصال کنترل کننده سیگنال (گیرنده)

کنترل کننده سیگنال تابعی است که با ارسال سیگنال مرتبط اجرا می شود. جنگو دو راه برای اتصال یک هندلر به یک فرستنده سیگنال ارائه می دهد. می توانیم سیگنال را به صورت دستی وصل کنیم یا می توانیم از دکوراتور receiver استفاده کنیم.

اتصال دستی

اگر بخواهیم این کار را به صورت دستی انجام دهیم، می توانیم این کار را به این صورت انجام دهیم:

 from orders . signals import order_confirmed order_confirmed . connect ( < the_signal_handler_function > )

با استفاده از دکوراتور

با استفاده از دکوراتور @receiver ، می‌توانیم یک فرستنده سیگنال را با یک کنترل‌کننده سیگنال خاص مرتبط کنیم. بیایید از این روش استفاده کنیم. تابعی ایجاد کنید که موجودی را با ارسال سیگنال order_confirmed به روز کند. این کنترل کننده در برنامه products خواهد بود. فایل products/signals.py را باز کرده و کد زیر را در آن قرار دهید:

 from django . dispatch import receiver from orders . signals import order_confirmed @receiver ( order_confirmed ) def update_quantity_on_order_confirmation ( sender , ** kwargs ) : """ Signal handler to update the inventory when an order is confirmed. """ product = sender . product product . quantity -= sender . quantity product . save ( ) print ( f"Quantity updated for { product . name } . New quantity: { product . quantity } " )

تابع handler همیشه باید آرگومان های sender و **kwargs در خود داشته باشد. اگر تابع را بدون آرگومان **kwargs بنویسیم، جنگو خطا خواهد کرد. این یک اقدام پیشگیرانه برای اطمینان از اینکه تابع کنترل کننده ما قادر به رسیدگی به آرگومان ها در آینده در صورت بروز آنها است، است.

سیگنال های داخلی در جنگو

جنگو با برخی سیگنال‌های داخلی برای موارد استفاده مختلف عرضه می‌شود. دارای سیگنال هایی است که توسط سیستم مدل ارسال می شود. دارای سیگنال های ارسال شده توسط django-admin است. دارای سیگنال هایی است که در طول چرخه درخواست/پاسخ ارسال می شوند. دارای سیگنال هایی است که توسط بسته های پایگاه داده ارسال می شود. همچنین هنگام اجرای آزمایش ها سیگنال هایی ارسال می شود.

سیگنال های مدل

سیگنال های مدل سیگنال هایی هستند که توسط سیستم مدل ارسال می شوند. اینها سیگنال هایی هستند که زمانی که رویدادهای مختلفی در مدل های ما رخ می دهند یا در شرف وقوع هستند ارسال می شوند. ما می توانیم به سیگنال ها مانند این دسترسی داشته باشیم: django.db.models.signals.<the_signal_to_use>

pre_save

این سیگنال در ابتدای متد model save() ارسال می شود. آرگومان های مختلفی را با آن ارسال می کند: sender کلاس مدلی است که سیگنال را ارسال می کند، instance نمونه واقعی ذخیره شده است، raw یک مقدار بولی است که اگر مدل دقیقاً همانطور که ارائه شده ذخیره شود، درست است.

post_save

این سیگنال در انتهای متد مدل save() ارسال می شود. این سیگنال به ویژه مفید است و می توان از آن در موارد مختلف استفاده کرد. برای مثال در پروژه my_shop می توانیم از آن برای اطلاع رسانی به اپلیکیشن products در صورت تایید سفارش استفاده کنیم. مشابه سیگنال pre_save ، برخی از آرگومان‌ها را نیز به همراه ارسال می‌کند - فیلدهای sender ، instance ، created ، raw ، using و update_fields. بیشتر این آرگومان‌ها اختیاری هستند، اما درک تأثیرات استفاده از آن‌ها به اطمینان از استفاده صحیح از سیگنال‌ها در برنامه‌مان کمک می‌کند.

سیگنال های درخواست/پاسخ

سیگنال‌های درخواست/پاسخ سیگنال‌هایی هستند که توسط چارچوب اصلی در طول چرخه درخواست/پاسخ ارسال می‌شوند. ما می توانیم به سیگنال ها مانند این دسترسی داشته باشیم: django.core.signals.<the_signal> .

درخواست_شروع شد

این سیگنال زمانی ارسال می شود که جنگو شروع به پردازش یک درخواست کند.

درخواست_تمام شد

این سیگنال زمانی ارسال می شود که جنگو ارسال یک پاسخ HTTP به یک کلاینت را تمام کند.

این چارچوب از تعداد زیادی سیگنال داخلی برای استفاده استفاده می کند. در مستندات سیگنال درباره آنها بیشتر بیاموزید.

نحوه استفاده از سیگنال های داخلی در پروژه

استفاده از سیگنال های داخلی در پروژه با استفاده از سیگنال های سفارشی تفاوت چندانی ندارد. تنها تفاوت این است که ما نیازی به تنظیم دستی ارسال سیگنال نداریم، زیرا به طور خودکار توسط فریم ورک ارسال می شود، چه گیرنده ای ثبت شده باشد یا خیر. به عبارت دیگر، لازم نیست به طور صریح متدی مانند Signal.send() را فراخوانی کنیم تا سیگنال های داخلی را راه اندازی کنیم، زیرا جنگو از آن مراقبت می کند.

برای مثال، بیایید ببینیم چگونه می‌توانیم از post_save برای نشان دادن تأیید سفارش و به‌روزرسانی موجودی استفاده کنیم. در فایل products/signal.py ، کد را به صورت زیر به روز کنید:

 from django . db . models . signals import post_save from django . dispatch import receiver from orders . models import Order @receiver ( post_save , sender = Order ) def update_quantity_on_order_confirmation ( sender , instance , created , ** kwargs ) : if created : product = instance . product product . quantity -= instance . quantity product . save ( ) else :

کد بالا سیگنال post_save را از models.signals وارد می کند. همچنین ماژول receiver را از django.dispatch و در نهایت مدل Order را از اپلیکیشن orders وارد می کنم.

در دکوراتور @receiver ، به غیر از درج سیگنال post_save به عنوان فرستنده، مدلی را که می‌خواهیم سیگنال‌ها را از آن گوش کنیم نیز درج می‌کنیم. دلیل این امر این است که همه مدل‌های پروژه ما سیگنال post_save را منتشر می‌کنند، پس می‌خواهیم مشخص کنیم که از کدام مدل به سیگنال‌ها گوش می‌دهیم.

در تابع handler، توجه داشته باشید که به روز رسانی موجودی تنها در صورتی اتفاق می افتد که گزینه created درست باشد. دلیل این امر این است که سیگنال post_save برای نمونه‌های ایجاد سفارش جدید و به‌روزرسانی سفارش‌ها ارسال می‌شود، پس می‌خواهیم موجودی را هنگام ایجاد سفارش جدید به‌روزرسانی کنیم.

در برنامه orders ، نمای confirm_order به روز می کنیم و بخشی را که سیگنال را به صورت دستی ارسال می کنیم حذف می کنیم، زیرا سیگنال post_save به طور خودکار توسط کلاس مدل Order ارسال می شود.

مثال های عملی

در حالی که استفاده از سیگنال‌ها برای تایید سفارش را دیده‌ایم، روش‌های مختلفی وجود دارد که سیگنال‌ها را می‌توان در پروژه‌های ما استفاده کرد، پس اجازه دهید به چند نمونه نگاه کنیم.

مثال 1: استفاده از سیگنال ها برای ایجاد خودکار پروفایل مشتری

برای گسترش پروژه تجارت الکترونیک، می‌توانیم برنامه‌ای برای مدیریت حساب داشته باشیم. اینجاست که ممکن است حساب‌های مختلفی برای کاربران سیستم خود ایجاد کنیم که در آن کاربران مدیریتی و سایر کاربرانی مانند مشتریان داشته باشیم. ما می‌توانیم سیستم خود را به گونه‌ای تنظیم کنیم که کاربرانی که در فرانت‌اند در سیستم ثبت‌نام می‌کنند، مشتری باشند، و می‌توانیم راه دیگری برای ایجاد ابرکاربران سیستم داشته باشیم. پس در این مورد، می‌توانیم یک برنامه برای مدیریت مشتری نیز داشته باشیم، اما مشتریانی را با ثبت نام ایجاد کنیم.

به این ترتیب اپلیکیشن مدیریت حساب‌ها مسئولیت ایجاد حساب‌ها را بر عهده خواهد داشت و پس از ایجاد حساب کاربری برای کاربر، پروفایل مشتری به‌طور خودکار برای او ایجاد می‌شود.

بیایید یک مثال را ببینیم:

 from django . db . models . signals import post_save from django . dispatch import receiver from django . contrib . auth . models import User from customers . models import Customer @receiver ( post_save , sender = User ) def create_customer_profile ( sender , instance , created , ** kwargs ) : if created : Customer . objects . create ( user = instance )

در این مثال کد، یک سیگنال برای ایجاد خودکار پروفایل مشتری هر زمان که کاربر جدیدی ثبت می شود، استفاده می شود. تابع create_customer_profile با استفاده از دکوراتور @receiver به سیگنال post_save برای مدل User متصل می شود. هنگامی که یک نمونه کاربر جدید ایجاد می شود (همانطور که با پرچم ایجاد شده نشان داده شده است)، این تابع با استفاده از مدیر مدل Customer برای ایجاد یک نمونه با ارجاع به کاربر تازه ثبت نام شده، یک نمایه مشتری مربوطه ایجاد می کند. این رویکرد فرآیند مرتبط کردن پروفایل های مشتری با ثبت نام های کاربر جدید را ساده می کند و کارایی و قابلیت نگهداری سیستم مدیریت کاربر برنامه را افزایش می دهد.

مثال 2: راه اندازی اعلان های ایمیل با سیگنال ها

در این مورد، ما می‌توانیم یک برنامه وبلاگ‌نویسی داشته باشیم که در آن نویسندگان از طریق ایمیل مطلع می‌شوند زمانی که خواننده نظری را برای آنها در وبلاگ خود می‌گذارد.

بیایید یک مثال را ببینیم:

 from django . db . models . signals import post_save from django . dispatch import receiver from django . core . mail import send_mail from blog . models import Comment @receiver ( post_save , sender = Comment ) def send_comment_notification ( sender , instance , created , ** kwargs ) : if created : subject = 'New Comment Notification' message = 'A new comment has been posted on your blog.' from_email = 'your@example.com' recipient_list = [ instance . blog . author . email ] send_mail ( subject , message , from_email , recipient_list )

کد بالا از سیگنال‌هایی برای راه‌اندازی اعلان ایمیل هنگام ارسال نظر جدید در وبلاگ استفاده می‌کند. تابع send_comment_notification به سیگنال post_save برای مدل Comment متصل می‌شود و اجرای آن در هر ذخیره را تضمین می‌کند. این تابع تحلیل می کند که آیا نظر به تازگی ایجاد شده است (به روز نشده است) و اگر چنین است، یک اعلان ایمیل با موضوع و پیام از پیش تعریف شده ایجاد می کند. ایمیل برای نویسنده وبلاگ ارسال می شود تا نظر جدید را به آنها اطلاع دهد. این رویکرد اعلان‌های ایمیل خودکار و بلادرنگ را برای نویسندگان وبلاگ فعال می‌کند و تعامل و تعامل کاربر با پلتفرم را افزایش می‌دهد.

نتیجه

در این آموزش، سیگنال‌های جنگو، چیستی و نحوه استفاده از آنها را توضیح داده‌ایم. ما همچنین نحوه تعریف سیگنال های سفارشی، سیگنال های داخلی و چند مورد استفاده واقعی از سیگنال ها را تحلیل کرده ایم.

خبرکاو