Web開発

Adding icons to a Bootstrap dropdown Bootply Sample Bootstrap button dropdown widget (replaces forms.Select)

from_queryset

wagtail wagtail/wagtail Welcome to Wagtail’s documentation modelcluster django-modelcluster taggit django-taggit (doc)

サバクラ両方で動く JavaScript の大規模開発を行うために 原文：Scaling Isomorphic Javascript Code (This is just for study, please contact me at tily05 atmark gmail.com if any problem.) 考えてみれば Model-View-Controller とか MVC ってよく聞くよね。実際どんなものか知ってる？ 抽象的に言うなら「オブジェクト情報の保持されるグラフィック・システム (つまり、ラスターではないグラフィック。ゲームとか) 上に構築された、表示系を中心としたアプリケーションにおいて、主要な機能どうしの関わりをうまく分離すること」とでも言おうか。もう少し深く考えを押し進めてみれば、これは当然、他のさまざまなアプリケーションにもあてはまる言葉 (bucket term ?) だ。 過去に多くの開発コミュニティが MVC による解決案を提供し、それによってよくあるユースケースにうまく対処し、地位を築くことができた。例をあげるなら、Ruby や Python コミュニティは Rails や Django を作り、MVC アーキテクチャを実現した。 こうした手法は Java, Ruby, Python といった他の言語では容易に受け入れらてきたが、Node.js について十分ではない。理由は単純で、それはただ、JavaScript が今や isomorphic な言語であるからだ。isomorphic というのは「ソースコードのどの行 (もちろん注目すべき例外もあるが) をとってみても、クライアント・サーバーの両方で実行できる」ということを意味している。表面的には無害に見えるが、この特徴のせいで現状の MVC ベースのパターンでは解決できない課題がたくさんある。 この記事では、まず現存するパターンをいくつか取り上げ、いかにそのようなパターンに関する実装や心配事が言語や環境に関わらず普遍的なものとなり得たか、そのようなパターンがどうして真に “isomorphic” な Javascript のソースコードにはあまり適していないのかを述べる。そして結論として、新しいパターン “Resource-View-Presenter” について述べる。 目次 デザインパターンは、アプリケーションの開発にとってなくてはならないオマンマのような存在である。アプリケーションやその環境についてのさまざまの心配事をカプセル化し、うまくまとめてくれる。ブラウザとサーバの間でこんなにもさまざまの心配事があるからね： View を作るとして、(たとえばサーバ側で) 一時的にしか存在しないのか、(たとえばブラウザ側で) 永続するべきものなのか？ View を作るとして、複数のユースケースやシナリオの間で再利用可能なものか？ View を作るとして、アプリケーション特有のタグやマークアップが使われているか？ ビジネスロジックをどこに記述すべきか？ (Model なのか Controller なのか) アプリケーションの持つ状態はどのように保持されアクセスされるのか？ 現存するパターンを取り上げ、上記の問題がどのように解決されているのか見てみよう： ...