🖐🏿 ⌛️ 👨🏿‍🔬 パングルメのレシピ 👨‍👧 📌 👩‍🎤

最近、パンガーマンレストランの予約サービスを開始しました。この中には、多かれ少なかれ典型的なdjangoサイトがあります。それがどのように機能するかを説明します（写真付き）。この記事は非常に巧妙なものではありませんが、誰かがいくつかのトリックやアイデアを見つけて、何らかの形で自分の人生を簡素化してくれることを願っています。

標準ツールボックスは、PostgreSQL、Django 1.4（+ GeoDjango）、Sentry、Celery（+ redis）、Fabricです。

スタートページ

スタートページに異常なものはありません：登録フォーム。私がすでに書いたように、ビューフォームは自作であり、そこからビューやフォームを使用していないことに気付いた後、ジャンゴ登録はinしげに切り取りました。モデルを誘引しようとしてプロジェクトのバグトラッカーが無効になりました:)

登録すると、挨拶状が送信され、htmlとして作成されます。 html-letterを送信するには、 templated-emailsを使用します。テンプレートには、すべての文字が保存されるemailsフォルダーがあります。各レターは、email.html（レターのhtmlバージョン）、email.txt（レターのテキストバージョン）、およびshort.txt（件名）の3つのファイルを含む独自のフォルダーにあります。

手紙は次のように送られます。

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

受信者のリストにユーザーまたは電子メールアドレスを送信できます。ナンセンスですが、シンプルで便利な、私たちはかなり長い間、さまざまなプロジェクトでこのアプローチを使用しています。

html-letterにはもう1つの問題があります-開発中にそれらをどのように見れば自分に絶えず送信するかはあまり明確ではありません。ローカルで確認するには、 django-eml-email-backend （送信する代わりにemlファイルに文字を保存する電子メールバックエンドを備えたダムアプリケーション）を使用します。ほとんどのメールクライアントは問題なくemlファイルを開きます（スペースによってもポップアップのプレビューがあります）。

わかりました、ザレギス

アカウントを登録して設定すると、ユーザーはメインページに移動します。

その上で、検索フォームに注意を払うことができます。

要素はもともと次のようにレイアウトされていました。

  <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>

連中はBEMに固執しようとしますが、入力はしばしばdivにラップされ、しばしばcssクラス、データ属性などを属性付けする必要があります。

Pythonコードでhtmlを縫うのは悪い味です。htmlはテンプレートにあるべきです。 jung内のテンプレート内のフォーム要素のレンダリングに影響を与える通常の組み込みツールはありません（ここでは、フィールドにデータの振る舞いを追加する必要があります）。このようなことから、レイアウトをねじ込むときにdjango-widget- tweaks （ bitbucket 、 github ）を非常に積極的に使用しているため、このアプリケーションではねじ込みプロセスを簡素化してハードにできます。

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

フィールドに何らかの種類の標準バインディングが必要な場合、htmlスニペットを作成し、{％include％}（次のようなもの）を介して接続できます。

  {% 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- {% render_field %}

は、既存の属性に属性（cssクラスなど）を追加することもできます。

  {% 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)

）。組み込みのdzhangovskyアプローチ-そのようなピースをマネージャに渡す-は、これを許可しません。マネージャーメソッドは、カスタムメソッドを既に持たないQuerySetを返します。フィルタリングのために、使用できるメソッドは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のエラーはサイトを動作不能にしません）、たとえば、そのようなサイトはテストが簡単です（セレンなしで最も確認できます）+書きやすいかもしれません

現時点では、ajaxに次のアプローチを使用します。ajaxと通常のリクエストは同じビューで処理されます。唯一の違いはテンプレートにあります。なぜなら ajaxテンプレートは通常のテンプレートの一部であるため、通常のテンプレートに接続します。通常のパターン：

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

Ajaxパターン：

  <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を追加しました。

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

つまりデコレータで通常のビューをラップし、データ属性をフォームに書き込むと、フォームがajaxになります。

しかし、このオプションは'restaurants/(ajax/)?list.html'

（これは'restaurants/(ajax/)?list.html'

、エラーの原因です）を繰り返します'restaurants/(ajax/)?list.html'

+ビューにはいくつかの戻り点があり、すべてをajaxで行う必要はありません（つまり、オプションは単純なチェックよりも悪いですデコレータ）。

したがって、彼らは@ajax_templateを拒否し、これまでのところこのオプションを決定しています。

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

showはTemplateResponseの子孫であり、ajaxリクエストの場合、最初にajaxサブフォルダーでテンプレートを試行します。 https://gist.github.com/2416695を参照してください

ショーには、私がいつも見逃していたもう2つの方法があります。それにはいくつかの微妙な点があり、すべてが素晴らしいわけではありません（たとえば、前のビューがリダイレクトを返した場合、.with_contextは落ちるでしょう）が、それを使用することはかなり可能です（そして問題はajaxとはほとんど関係ありません）。

つまり、Ajaxが存在しないかのようにサイトを作成し、必要に応じてテンプレートの必要な部分をサブフォルダーに入れて後で追加します。

何かを見つけた、レストランで突く

レストランのページに行きます。

また、ajaxがあります（注文フォームでは、利用可能な時間はajax-requestsによってチェックされます）が、別の方法で実装されます:)

カレンダーはクライアント上に構築されるため（jsがない場合は通常の入力フィールドがあります）、サーバーからhtmlではなくjsonを取得する方が簡単です。 django-tastypieの助けを借りて、私はすぐにAPIを構築し、それを通してjsonは目的のAPIに渡されます。これは、jsonを手で表示するビューを記述するよりも長くはありませんが、とにかくAPIが便利になり、スロットルや出力形式などのさまざまな利点が得られます。

別のプロジェクトでは、APIにdjango-pistonを使用しました。主観的に-django-tastypieの方がいいです。

このようなビューによって、APIの非常に原始的な（完全ではない）ヘルプが自動的に生成されます。

  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 （その後さらにオプションが追加されます）、予約に関するSMS通知- イモビス +セロリを介して行われます。

ファイナンス

PanGurmanでは、ユーザーは購入の支払いに使用する個人アカウントを持っています。ロボカッサの助けを借りて、友人を招待し、プロモーションコードを入力して補充できます。その後、何らかの方法で、さらにメソッドが追加されます。

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')

ここでは、選択肢を指定する方法に注意を払うことができます。さらに書きますが、魔法の定数はなく、誤ってinvite_bonusデータベースの代わりにinvite_bonusデータベースに書き込むことはできません-MoneyTransfer.INVITE_BONUSは常に単独であり、誤って書き込まれるとすぐにAttributeErrorになります（そしてオートコンプリートが表示されます）。

テーブルを予約しましたが、停止しますが、どのように機能しますか？

ヘルプページにアクセスしてください。テキストの一部であるこのページでは、明らかに、プログラマーの参加なしに編集者を編集する機会を与えるといいでしょう。

djangoにはこのためのフラットページがありますが、通常は別のアプローチを使用します：通常のテンプレートを使用してすべてのページを通常のビューにし、VCSにすべてを保存し、編集する必要があるテキストをdjango-flatblocksのブロックでマークします：

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

管理者の場合、テキストにカーソルを合わせると、編集するリンクが表示されます

（これは、テンプレートflatblocks / flatblock.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 %}

markdownのマークアップはブロックに保存されます。編集ページでは、 django-markitupのウィジェットを表示します（プレビューあり）。

一部のマークアップが許容されるサイト上のすべてのテキストは、django-markitupを使用して編集されます（たとえば、写真付きのレストランのインスピレーションを受けた説明）。マークダウンフィルターは、htmlタグに触れないように構成されているため、必要に応じて、任意のマークアップをテキストに追加できます。

また、拡張機能もねじ込まれています（ python-markdown-video ）。これにより、youtubeまたはvimeoへのリンクがビデオに変換されます-友好的な方法で、おそらくoembedを介してこれを行う必要があります。

レストランのパネル

レストランには、特別なパネルがあり、これを使用して、労働時間を制御できます（テーブルが利用可能な場合、利用できない場合）。パネルは、AdminSiteの別のインスタンスを通じて実装されます。「レストランマネージャー」として指定されているユーザーはそこにアクセスできます。微妙な点は、これらのユーザーにis_staffフラグを付けないことです。そうしないと、通常の管理パネルにアクセスできますが、これは望ましくありません。そして-通常のカスタム管理パネル。

[暴言]

多くの場合、Dzhangovka管理者には柔軟性がないなどと書かれています。 -私は人々が具体的に何を意味するのか理解できませんでした:)管理パネルはCRUD、レイアウト、およびデザインを「そのまま」提供します。 正統派の代替として、彼らは通常、ダッシュボードを書くためのある種のフレームワークを提供します-これはCRUDに垂直なものであり、dzhangovskoy管理パネル（ django-admin-tools 、 nexus ）のためのフレームワークがあります。

何らかの種類の相互作用がCRUDに適合しない場合-問題はありませんが、管理領域内のどこからでもビューを記述してそれにリンクすることを妨げるものはありません（ここでは、readonly_fieldsとlist_displayが便利なことがよくあります;テンプレートをオーバーライドすることもできます）。数年間、欲望の管理パネルを投げたり、書き直したりすることは決してありませんでした。私たちはすべてのプロジェクトでそれを使用し、多くの時間を節約しました。 おそらく、プロジェクトの詳細はこれですか、それとも私は本当に明らかな何かを見逃しています、私は知りません。

[暴言]

管理パネルでは、raw_id_fieldsの代わりに、恐ろしい名前django- salmonellaのアプリケーションを積極的に使用します。これは、ウィジェットに「感染」し、有用な動作を伴う関連レコードを選択します（FKおよびM2Mの場合：

オブジェクトのIDに加えて、その名前が表示されます（ajaxによって更新されます）。名前をクリックすると、オブジェクトを変更するページにすぐにアクセスできます。これも便利です。

テスト

テストのために、彼らは工場の少年（フォーク）を使い始めました。それ以来、ファクトリーボーイに非常に便利なものが1つ登場しました。RelatedFactoryです。 SubFactoryのようなもので、その反対です（たとえば、ユーザーのファクトリを作成して、すぐにプロファイルを作成できます）。ドキュメントはここで読むことができます。例：

 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番目のpythonのサポートを追加してfactory-boyでpull-requestを行いましたが、3番目のpythonは別のストーリーのトピックです）

Django 1.4には、テストに関するもう1つのトリックがあります。デフォルトでは、PBKDF2アルゴリズムがパスワードのハッシュに使用されています。 PBKDF2では、セキュリティ機能の1つが低速です。しかし、セキュリティとは別に、低速はさらに低速を保証します:)メインサイトではこれはまったく問題ではありません（ユーザーはログインするたびに登録せず、遅延は小さいです）が、テストでは、特に工場を使用する場合、これが重要なことであることが判明しました-boyとハッシュを使用してパスワードを割り当てることにより、多くのユーザーを作成します。

PanGurmanの場合、test_settings.pyにこの行をインストールすると、テストが2倍に加速されました。

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

パングルメのレシピ