पान लौकी से रेसिपी

हाल ही में PanGurman रेस्तरां की बुकिंग के लिए एक सेवा शुरू की है। इसके अंदर एक या अधिक विशिष्ट django साइट है। मैं आपको यह बताने की कोशिश करूंगा कि यह कैसे काम करता है (चित्रों के साथ) लेख में सुपर-चालाक कुछ भी नहीं होगा, लेकिन मुझे उम्मीद है कि कोई व्यक्ति कुछ चाल या विचारों को उपयोगी पाएगा और जीवन को किसी तरह आसान बना देगा।

मानक टूलबॉक्स PostgreSQL, Django 1.4 (+ GeoDjango), संतरी, अजवाइन (+ रेडिस), फैब्रिक है।

प्रारंभ पृष्ठ

प्रारंभ पृष्ठ पर कुछ भी असामान्य नहीं है: पंजीकरण फॉर्म। जैसा कि मैंने पहले ही लिखा था , दृश्य रूप स्व-निर्मित होते हैं, डीजंगो-पंजीकरण के बाद मुझे अहसास हुआ कि मैंने वहां से किसी भी दृश्य या रूप का उपयोग नहीं किया है, मैं मॉडल को लुभाने की कोशिश कर रहा था और परियोजना का बग ट्रैकर अक्षम कर दिया गया था :)

जब आप पंजीकरण करते हैं, तो एक बधाई पत्र भेजा जाता है, इसे html के रूप में बनाया जाता है। Html- पत्र भेजने के लिए हम टेम्प्लेटेड-ईमेल का उपयोग करते हैं: टेम्प्लेट में एक ईमेल फ़ोल्डर होता है जिसमें सभी अक्षर संग्रहीत होते हैं। प्रत्येक पत्र अपने स्वयं के फ़ोल्डर में होता है जिसमें 3 फाइलें होती हैं: email.html (पत्र का HTML-संस्करण), email.txt (पत्र का पाठ संस्करण) और short.txt (विषय)।



पत्र इस तरह भेजे जाते हैं:

send_templated_email([user], 'emails/activation', context=context) 

आप प्राप्तकर्ताओं की सूची में उपयोगकर्ता या सिर्फ ईमेल पते भेज सकते हैं। बकवास, लेकिन सरल और सुविधाजनक, हम विभिन्न परियोजनाओं पर काफी समय से इस दृष्टिकोण का उपयोग कर रहे हैं।

Html-अक्षरों के साथ एक और समस्या है - यह बहुत स्पष्ट नहीं है कि खुद को लगातार भेजे बिना विकास के दौरान उन्हें कैसे देखना है। स्थानीय रूप से जांच करने के लिए, हम django-eml-email-backend (एक ईमेल बैकएंड के साथ एक डंब एप्लिकेशन का उपयोग करते हैं जो भेजने के बजाय इमला फ़ाइलों को अक्षर बचाता है)। अधिकांश ईमेल क्लाइंट समस्याओं के बिना ईएमएल फाइलें खोलते हैं (अंतरिक्ष द्वारा पॉप-अप पर भी पूर्वावलोकन है)।

ठीक है, ज़रीगिस

एक खाते को पंजीकृत करने और स्थापित करने के बाद, एक व्यक्ति मुख्य पृष्ठ पर पहुंच जाता है।



उस पर आप खोज फ़ॉर्म पर ध्यान दे सकते हैं।



तत्वों को मूल रूप से इस तरह रखा गया था:

  <div class="b-filter_selector time"> <select name="persons" data-behavior="Chosen"> <option value="1">1 </option> <option value="2" selected="selected>2 </option> <option value="3">3 </option> </select> </div> 

लोग बीईएम से चिपके रहने की कोशिश करते हैं, इनपुट अक्सर डिव में खुद को लपेटते हैं और उन्हें अक्सर कुछ सीएसएस-क्लास, डेटा-एट्रिब्यूट्स आदि की आवश्यकता होती है।

अजगर कोड में सीटीएम खराब स्वाद है, html को टेम्पलेट में होना चाहिए। जंग में टेम्पलेट में फार्म तत्वों के प्रतिपादन को प्रभावित करने के लिए कोई सामान्य अंतर्निहित उपकरण नहीं है (और यहां हमें फ़ील्ड में डेटा-व्यवहार को जोड़ने की आवश्यकता है)। इस तरह की चीजों के कारण, हम लेआउट को स्क्रू करते समय django-widget-tweaks ( bitbucket , github ) का बहुत सक्रिय रूप से उपयोग करते हैं, यह एप्लिकेशन स्क्रू करने की प्रक्रिया को सरल और डी-हार्ड करने की अनुमति देता है।

 <div class="b-filter_selector time"> {% render_field search_form.persons data-behavior='Chosen' %} </div> 

यदि आपको फ़ील्ड के लिए किसी प्रकार के मानक बंधन की आवश्यकता है, तो हम एक html स्निपेट बनाते हैं, जिसे बाद में {% शामिल%} (कुछ इस तरह से) के माध्यम से जोड़ा जा सकता है:

  {% comment %} : {% include "inc/input.html" with field=form.query div_classes="search" no_label=0 %} {% endcomment %} {% load widget_tweaks %} {% if no_label != 1 %}{{ field.label_tag }}{% endif %} <div class="b-input {{ div_classes }} {% if field.errors %}error{% endif %}"> {{ field|add_class:'b-input_input' }} </div> 

वही एरर आउटपुट के लिए जाता है।

django-widget-tweaks से {% render_field %} मौजूदा विशेषताओं के लिए विशेषता (उदाहरण के लिए, सीएसएस कक्षाएं) भी जोड़ सकते हैं:

  {% render_field form.emails rows="2" class+="b-input_textarea gray" autofocus="" %} {% include "inc/errors.html" with errors=form.emails.errors %} 

आज उपलब्ध ब्लॉक

इस ब्लॉक में हमारे पास 5 रेस्तरां हैं जो आज बुकिंग के लिए उपलब्ध हैं। वे इस तरह से बाहर निकलते हैं:

 restaurants = Restaurant.objects.enabled().free_today_in_city(city).prefetch_related('scenes')[:5] 

जैसा कि आप देख सकते हैं, इसके तरीकों की श्रृंखला यहाँ ( .enabled().free_today_in_city(city) ) में .enabled().free_today_in_city(city) । अंतर्निहित dzhangovsky दृष्टिकोण - प्रबंधक को ऐसे टुकड़े लेना - यह अनुमति नहीं देता है, क्योंकि प्रबंधक विधियां एक क्वेरीस लौटाती हैं, जिसमें पहले से ही कोई कस्टम विधि नहीं है - फ़िल्टर करने के लिए, यह पता चला है कि आप केवल अपने तरीकों में से 1 का उपयोग कर सकते हैं।

इस सीमा के आसपास जाने के लिए, django-model-utils से PassThroughManager का उपयोग करें और एक प्रबंधक के बजाय एक QuerySet लिखें:

  class RestaurantQueryset(QuerySet): def enabled(self): return self.filter(enabled=True) def free_today_in_city(self, city): today = city.now().date() return self.filter(city=city).free(today) def free(self, date): # ... class Restaurant(models.Model): # ... objects = PassThroughManager.for_queryset_class(RestaurantQueryset)() 

ऐसे "स्टेरॉयड पर प्रबंधक" प्राप्त होते हैं (मैंने एक तस्वीर नहीं लेने का फैसला किया :))। हम मानक प्रबंधकों के बजाय पूरे प्रोजेक्ट में उनका उपयोग करते हैं।

"सभी देखें" पर क्लिक करें

... और हम रेस्तरां की एक सूची के साथ पृष्ठ पर आते हैं। यह पृष्ठ एक शानदार खोज फ़ॉर्म है, जिसके परिणाम Ajax द्वारा अपडेट किए जाते हैं।



मेरे पास js के बारे में एक छोटा व्यक्तिगत "सनक" है: साइट को बिना js के प्रयोग करने योग्य होना चाहिए। यह विकसित होने पर कुछ फायदे देता है। स्पष्ट लोगों के अलावा (js में एक त्रुटि साइट को निष्क्रिय नहीं बनाती है) कम स्पष्ट भी हैं: उदाहरण के लिए, ऐसी साइट का परीक्षण करना आसान है (आप इसे सेलेनियम के बिना सबसे अधिक जांच सकते हैं) + इसे लिखना आसान हो सकता है।

फिलहाल, हम निम्नलिखित दृष्टिकोण को अजाक्स का उपयोग करते हैं: अजाक्स और नियमित अनुरोधों को एक ही दृश्य द्वारा संसाधित किया जाता है, केवल अंतर टेम्पलेट में है। क्योंकि अजाक्स टेम्पलेट एक नियमित टेम्पलेट का हिस्सा है, तो हम इसे एक नियमित टेम्पलेट में जोड़ते हैं। सामान्य पैटर्न:

  {% extends 'base.html' %} <!-- : ,     --> ... <div class="b-search-results_result"> {% include 'restaurants/ajax/list.html' %} </div> ... <!-- :  ,    --> 

अजाक्स पैटर्न:

  <ul class="b-search-results_result_list"> {% for restaurant in restaurants %} <li>...</li> {% endfor %} </ul> 

टेम्पलेट का चयन request.is_ajax () के आधार पर किया जाता है; क्लाइंट पर घोषणात्मक js है, जो किसी भी साधारण HTML फॉर्म को ajax में बदल सकता है:

  def restaurant_list(request, city_slug): # ... response = TemplateResponse(request, 'restaurants/list.html', {...}) if request.is_ajax(): response.template_name = 'restaurants/ajax/list.html' return response 

PanGurman में, मैंने इसके साथ थोड़ा प्रयोग करने का फैसला किया। सबसे पहले यह @ajax_template डेकोरेटर था, जिसने व्यू में अजाक्स जोड़ा:

  @ajax_template('restaurants/ajax/list.html') def restaurant_list(request, city_slug): # ... return TemplateResponse(request, 'restaurants/list.html', {...}) 

यानी आप डेकोरेटर में सामान्य दृश्य को लपेटते हैं, प्रपत्र के लिए डेटा-विशेषता लिखते हैं और यह है: फ़ॉर्म ऐजैक्स बन जाता है।

लेकिन यह विकल्प 'restaurants/(ajax/)?list.html' दोहराता है (जो परेशान करता है और त्रुटियों का एक स्रोत है), + दृश्य में कई वापसी बिंदु हो सकते हैं और सब कुछ अजाक्स करने की आवश्यकता नहीं है (जिसका अर्थ है कि विकल्प एक साधारण जांच के बिना बदतर है) डेकोरेटर)।

इसलिए, उन्होंने @ajax_template को अस्वीकार कर दिया और अब तक इस विकल्प पर निर्णय लिया है:

  def restaurant_list(request, city_slug): # ... return show(request, 'restaurants/list.html', {...}) 

शो TemplateResponse का वंशज है, जो, अजाक्स अनुरोधों के लिए, पहले अजाक्स सबफ़ोल्डर में टेम्पलेट आज़माता है। Https://gist.github.com/2416695 देखें

शो में कुछ और विधियां हैं, जिन्हें मैंने हमेशा याद किया - लेकिन शायद यह पर्याप्त नहीं था, क्योंकि इसके साथ कुछ सूक्ष्मताएं हैं और सब कुछ अद्भुत नहीं है (उदाहरण के लिए, .with_context गिर जाएगा यदि पिछले दृश्य ने पुनर्निर्देशित किया है), लेकिन इसका उपयोग करना काफी संभव है (और समस्याओं का अजाक्स से बहुत कम संबंध है)।

संक्षेप में, हम साइट बनाते हैं जैसे कि अजाक्स मौजूद नहीं है, और बाद में, जहां आवश्यक हो, टेम्पलेट के आवश्यक भाग को एक सबफ़ोल्डर में डालकर इसे जोड़ दें।

कुछ मिला, एक रेस्तरां में प्रहार किया

हम रेस्तरां पृष्ठ पर जाते हैं।



इसका एक अजाक्स भी है (आदेश रूप में, उपलब्ध समय को अजाक्स-अनुरोधों के माध्यम से जांचा जाता है), लेकिन इसे दूसरे तरीके से लागू किया जाता है :)

कैलेंडर क्लाइंट पर बनाया गया है (js के बिना सामान्य इनपुट फ़ील्ड होंगे) और इसलिए सर्वर से json, html नहीं, प्राप्त करना आसान है। Django-tastypie की मदद से, मैंने जल्दी से API का निर्माण किया, और इसके माध्यम से वांछित व्यक्ति को json दिया गया। यह आपके हाथों से json देने वाला दृश्य लिखने की तुलना में अधिक लंबा नहीं है, लेकिन एपीआई वैसे भी काम आएगा + हमें थ्रॉटलिंग और आउटपुट प्रारूपों जैसे विभिन्न उपहार मिलते हैं।

एक अन्य परियोजना में, उन्होंने एपीआई के लिए django- पिस्टन का उपयोग किया; विषयगत रूप से - django-tastypie अच्छे हैं।

एपीआई के लिए एक बहुत ही आदिम (और पूरी तरह से नहीं) मदद स्वचालित रूप से इस तरह के एक दृश्य द्वारा उत्पन्न होती है:

  def _api_resources(api): resources = {} api_name = api.api_name for name in sorted(api._registry.keys()): resource = api._registry[name] resources[name] = { 'list_endpoint': api._build_reverse_url("api_dispatch_list", kwargs={ 'api_name': api_name, 'resource_name': name, }), 'schema': api._build_reverse_url("api_get_schema", kwargs={ 'api_name': api_name, 'resource_name': name, }), 'doc': resource.__doc__, 'resource': resource } return resources def browse(request, api): resources = _api_resources(api) return TemplateResponse(request, 'tasty_browser/index.html', { 'api': api, 'resources': resources }) 

टेम्पलेट:

  <h1>API {{ api.api_name }}</h1> <table class='tastypie-api'> <tr><th>Resource</th><th>url</th><th>Structure</th><th>Description</th></tr> {% for name, resource in resources.items %} <tr> <td>{{ name }}</td> <td> <a href='{{ resource.list_endpoint }}?format=json'> {{ resource.list_endpoint }}</a> </td> <td> <a href='{{ resource.schema }}?format=json'> {{ resource.schema }}</a> </td> <td> {{ resource.doc }} </td> </tr> {% endfor %} </table> 

आप यहां देख सकते हैं: http://pangurman.ru/api-docs/

भुगतान को django-robokassa (फिर अधिक विकल्प जोड़े जाएंगे), आरक्षण के बारे में एसएमएस सूचनाओं - imobis + अजवाइन के माध्यम से खराब कर दिया जाता है ।

वित्त

PanGurman में, उपयोगकर्ता के पास एक व्यक्तिगत खाता है जिसमें से खरीदारी के लिए भुगतान करना है। आप इसे Robokassa की मदद से, मित्रों को आमंत्रित करते हुए, प्रचारक कोड दर्ज करके फिर से भर सकते हैं। फिर, किसी भी तरह से, अधिक तरीकों को जोड़ा जाएगा।

Fowler को पढ़ने के बाद, मैं कई वर्षों से "व्यक्तिगत खाते" के कार्यान्वयन के लिए निम्नलिखित दृष्टिकोण का उपयोग कर रहा हूं: राशि कहीं भी संग्रहीत नहीं है (हालांकि, इसे कभी-कभी कैश किया जा सकता है), हम डेटाबेस में व्यक्तिगत खाते में लेनदेन संग्रहीत करते हैं। यह आपको स्वाभाविक रूप से संचालन के इतिहास को प्राप्त करने की अनुमति देता है + त्रुटियों से बचाता है।

उदाहरण के लिए, यदि भुगतान प्रणाली के माध्यम से कोई व्यक्ति खरीद के लिए भुगतान करने के लिए अपर्याप्त राशि का भुगतान करता है, तो वह राशि पहले व्यक्तिगत खाते में जमा की जाएगी, फिर वह लिखने का प्रयास करेगा, बहस विफल हो जाएगी और व्यक्ति को बिना खरीद के छोड़ दिया जाएगा, लेकिन खाते में राशि के साथ।

मामूली बदलावों के साथ प्रोजेक्ट से समान मॉडल भटकता है:

  class MoneyTransfer(models.Model): PURCHASE = 'purchase' ROBOKASSA = 'robokassa' INVITE_BONUS = 'invite-bonus' REFUND = 'refund' PROMOCODE = 'promocode' TRANSFER_TYPE_CHOICES = ( (u'  ', ( (PURCHASE, u' '), )), (u' ', ( (ROBOKASSA, u'  '), (INVITE_BONUS, u'   '), (PROMOCODE, u' '), (REFUND, u''), )), ) user = models.ForeignKey(User, verbose_name=u'') amount = models.DecimalField(u'', max_digits=10, decimal_places=2) created_at = models.DateTimeField(u'/ ', auto_now_add=True) comment = models.CharField(u'', max_length=255, blank=True, null=True) transfer_type = models.CharField(u'', max_length=20, null=True, blank=True, choices=TRANSFER_TYPE_CHOICES) content_type = models.ForeignKey(ContentType, null=True, blank=True) object_id = models.PositiveIntegerField(null=True, blank=True) reason = GenericForeignKey('content_type', 'object_id') 

यहां आप विकल्पों को निर्दिष्ट करने के तरीके पर ध्यान दे सकते हैं। अधिक लिखें, लेकिन कोई जादू स्थिरांक नहीं हैं और आप गलत तरीके से आमंत्रण-बोनस के बजाय Inv_bonus डेटाबेस में नहीं लिख सकते हैं - MoneyTransfer.INVITE_BONUS हमेशा अकेला होता है और गलत तरीके से लिखे जाने पर (तुरंत-पूर्ण प्रकट होता है) एट्रीब्यूट के साथ गिर जाएगा।

हमने एक टेबल बुक की, लेकिन रुक गए, लेकिन यह कैसे काम करता है?

सहायता पृष्ठ पर जाएं। इस पृष्ठ पर, पाठ का हिस्सा, जाहिर है, संपादकों को प्रोग्रामर की भागीदारी के बिना संपादित करने का अवसर देना अच्छा होगा।



Django में इसके लिए फ़्लैटपेज हैं, लेकिन हम आमतौर पर एक अलग दृष्टिकोण का उपयोग करते हैं: हम सभी पृष्ठों को सामान्य टेम्पलेट्स के साथ सामान्य दृश्य बनाते हैं, VCS में सब कुछ संग्रहीत करते हैं, और पाठ के उन टुकड़ों को चिह्नित करते हैं जिन्हें django-flatblock से ब्लॉक के साथ संपादित करने की आवश्यकता होती है :

  <div class="b-text"> {% flatblock "how-it-works" 600 %} </div> 

प्रवेश के लिए, पाठ पर मँडरा संपादित करने के लिए एक लिंक प्रदर्शित करता है
(यह आपके टेम्प्लेट फ्लैटब्लॉक / फ्लैटब्लॉक.html सेट करके किया जाता है):

  {% load url from future %} {% load markup %} {% if user.is_staff %} <div class="b-flatblock-edit"> <a class="flatblock-edit-link markitup-flatblocks-edit-icon" title = " " href='{% url "edit_flatblock" flatblock.pk %}?next={{request.path}}'> </a> {{ flatblock.content|markdown:"video" }} </div> {% else %} {{ flatblock.content|markdown:"video" }} {% endif %} 

मार्कडाउन में मार्कअप ब्लॉक में संग्रहीत किया जाता है, एडिट पेज पर हम django-markitup (पूर्वावलोकन के साथ) से विजेट दिखाते हैं:



साइट पर सभी ग्रंथ जिसमें कुछ मार्कअप स्वीकार्य हैं, django-markitup (उदाहरण के लिए, तस्वीरों के साथ रेस्तरां के प्रेरित विवरण) का उपयोग करके संपादित किए जाते हैं। मार्कडाउन फ़िल्टर को इस तरह से कॉन्फ़िगर किया गया है कि यह HTML टैग्स को न छुए, ताकि ज़रूरत पड़ने पर किसी भी मार्कअप को टेक्स्ट में जोड़ा जा सके।
और, विस्तार भी खराब कर दिया गया है ( अजगर-मार्कडाउन-वीडियो ), जो वीडियो में यूट्यूब या वीमियो के लिंक को बदल देता है - एक सौहार्दपूर्ण तरीके से, आपको संभवतः oembed के माध्यम से ऐसा करने की आवश्यकता है।

रेस्तरां पैनल

रेस्तरां के लिए एक विशेष पैनल है जिसके माध्यम से वे अब काम के घंटे (जब टेबल उपलब्ध हैं, जब नहीं) को नियंत्रित कर सकते हैं। पैनल एडमिनसाइट के एक और अलग उदाहरण के माध्यम से लागू किया गया है। "रेस्तरां प्रबंधक" के रूप में नामित किए गए उपयोगकर्ता वहां पहुंच सकते हैं। सूक्ष्मता यह है कि इन उपयोगकर्ताओं के पास is_staff ध्वज नहीं होना चाहिए, अन्यथा वे सामान्य व्यवस्थापक पैनल में जा सकेंगे, जो वांछनीय नहीं होगा। और इसलिए - सामान्य कस्टम व्यवस्थापक पैनल।

[शेख़ी पर]
यह अक्सर लिखा जाता है कि, वे कहते हैं, Dzhangovka व्यवस्थापक अनम्य है और इसी तरह। - मुझे समझ नहीं आया कि लोग विशेष रूप से क्या मतलब रखते हैं :) व्यवस्थापक पैनल सीआरयूडी, लेआउट और डिज़ाइन "बॉक्स से बाहर" प्रदान करता है, और यदि आप जानते हैं कि क्या कॉन्फ़िगर किया जा सकता है और क्या मुश्किल है, तो कोई समस्या नहीं है। रूढ़िवादी विकल्पों के रूप में, वे आमतौर पर डैशबोर्ड लिखने के लिए किसी प्रकार की रूपरेखा प्रदान करते हैं - यह सीआरयूडी के लिए एक लंबवत बात है, और dzhangovskoy व्यवस्थापक पैनल ( django-admin-tools , neusus) के लिए ऐसे ढांचे हैं।

यदि किसी प्रकार का इंटरैक्शन सीआरयूडी में फिट नहीं होता है - कोई समस्या नहीं है, तो कुछ भी आपको अपना दृष्टिकोण लिखने और व्यवस्थापक क्षेत्र में कहीं से इसे लिंक करने से रोकता है (readonly_fields और list_display अक्सर यहां सुविधाजनक होते हैं; आप टेम्पलेट को ओवरराइड भी कर सकते हैं)। कई वर्षों से इच्छा के व्यवस्थापक पैनल को फेंकना या फिर से लिखना कभी नहीं उठता है, हम इसे सभी परियोजनाओं में उपयोग करते हैं, यह बहुत समय बचाता है। शायद परियोजनाओं की बारीकियां यह हैं, या मैं वास्तव में कुछ स्पष्ट याद करता हूं, मुझे नहीं पता।
[शेख़ी]

व्यवस्थापक पैनल में, raw_id_fields के बजाय, हम सक्रिय रूप से डरावना नाम django-salmonella के साथ एक एप्लिकेशन का उपयोग करते हैं, जो उपयोगी व्यवहार (FK और M2M के लिए) से संबंधित रिकॉर्ड का चयन करने के लिए "संक्रमित" विगेट्स:





ऑब्जेक्ट की आईडी के अलावा, इसका नाम दिखाई देता है (ajax द्वारा अद्यतन); नाम पर क्लिक करके आप तुरंत ऑब्जेक्ट बदलने के लिए पेज पर पहुंच सकते हैं, जो सुविधाजनक भी है।

परीक्षण

परीक्षणों के लिए, उन्होंने फैक्टरी-बॉय (कांटा) का उपयोग करना शुरू कर दिया, जिसके बारे में यह पहले से ही हब पर था उस समय से, कारखाने-लड़के में एक सुपर-उपयोगी चीज दिखाई दी: संबंधितफैक्टरी। यह सबफैक्टिव की तरह है, बस विपरीत (उदाहरण के लिए, आप उपयोगकर्ता के लिए एक कारखाना बना सकते हैं, जो तुरंत उसके लिए एक प्रोफ़ाइल बना देगा)। प्रलेखन यहाँ पढ़ा जा सकता है । एक उदाहरण:

 class ProfileF(factory.DjangoModelFactory): FACTORY_FOR = Profile city = factory.SubFactory(CityF) balance = 0 @classmethod def _prepare(cls, create, **kwargs): #  'balance=555' balance = kwargs.pop('balance') profile = super(ProfileF, cls)._prepare(create, **kwargs) if balance > 0: MoneyTransferF(user=profile.user, amount=balance) return profile class UserF(factory.DjangoModelFactory): FACTORY_FOR = User username = factory.Sequence(lambda n: "username%s" % n) first_name = factory.Sequence(lambda n: u" %s" % n) last_name = factory.Sequence(lambda n: u" %s" % n) email = factory.Sequence(lambda n: "email%s@example.com" % n) is_staff = False is_active = False is_superuser = False password = '123' profile = factory.RelatedFactory(ProfileF, 'user') @classmethod def _prepare(cls, create, **kwargs): kwargs['password'] = make_password(kwargs['password']) return super(UserF, cls)._prepare(create, **kwargs) 

अब परीक्षणों में आप इस तरह लिख सकते हैं:

 user = UserF(profile__balance=100) 

वार्म-अप के रूप में, मैंने फैक्ट्री-बॉय में 3-अजगर के समर्थन के साथ एक पुल-रिक्वेस्ट बनाई, लेकिन 3rd अजगर एक अलग कहानी के लिए एक विषय है)

Django 1.4 में परीक्षणों के साथ एक और चाल है। डिफ़ॉल्ट रूप से, PBKDF2 एल्गोरिथ्म पासवर्ड का उपयोग करने के लिए उपयोग किया गया है। PBKDF2 में, सुरक्षा सुविधाओं में से एक इसकी कम गति है। लेकिन सुरक्षा के अलावा, कम गति भी कम गति सुनिश्चित करती है :) मुख्य साइट पर यह एक समस्या नहीं है (उपयोगकर्ताओं को जितनी बार वे लॉग इन करते हैं, और विलंब छोटा है) दर्ज नहीं करते हैं, लेकिन परीक्षणों में यह पता चला है कि यह एक महत्वपूर्ण बात है, खासकर जब आप कारखाने का उपयोग करते हैं -boy और कई उपयोगकर्ताओं को हैश के माध्यम से एक पासवर्ड असाइन करके बनाएं।

PanGurman के मामले में, इस लाइन की स्थापना में test_settings.py ने परीक्षणों को 2 गुना तेज कर दिया:

  PASSWORD_HASHERS = ['django.contrib.auth.hashers.MD5PasswordHasher']