フレームワークのジレンマで書いた考えを実践してみる

フレームワークのジレンマ

続フレームワークのジレンマ

TO DOではなく、NOT TO DOの定義のほうが大事

競合フレームワークと比べたら負けだと思っている


つらつらとフレームワークのジレンマシリーズを書いてみましたが、思ってるだけ・考えてるだけでは
何も起こらないので実践して検証してみる。


まずはリリースプラン。どうせなら楽しくやりたいので、わかりやすく覚えやすいコードネームをつけてみた。
確定じゃないけど、晒してみる。


ver : コードネーム
0.2 : Menu : 1.0へ向けての機能の洗い出し。これ以上大きく機能は増やさない。増やす場合は、1.0以降の機能追加として配置。
0.2.3.5 : 機能のブラッシュアップ。Testの追加とJavaDocの追記。
0.2.3.6 : サブプロジェクトの分離。必要のないサブプロジェクトは削除。
0.2.3.7 : いまんところ未定
0.3 : Diet : 一旦開発ブランチへ全て保管し、機能を最小限まで削る。アーキテクチャの基本を確定させる。
0.4 : Core : HTTP/HTTPSを主としたアプリケーションの機能。エラー処理・テスト支援機能。
0.5 : Rest : REST/Ajaxを主とした機能。ちょっと一休みって意味もある。
0.6 : Star : Flex/AIRからの接続機能
0.7 : Silver : Silverlightからの接続機能

バグ修正はこのリリースプランに則らず順次行う。


肝はコードネーム「Diet」になりそう。
ポリシーとかTODO/NOT TO DOも順次晒していこうかとおもっとります。

DjangoのURLConf相当

上のリリースプランにもれてましたが、DjangoのURLConf相当のものを入れようかなと考えています。

DjangoのURLConfは以下のような感じです。

Here’s what a URLconf might look like for the Reporter/Article example above:
======================================================
from django.conf.urls.defaults import *

urlpatterns = patterns('',
(r'^articles/(\d{4})/$', 'mysite.views.year_archive'),
(r'^articles/(\d{4})/(\d{2})/$', 'mysite.views.month_archive'),
(r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'mysite.views.article_detail'),
)
======================================================
(途中略)

For example, if a user requested the URL “/articles/2005/05/39323/”, Django would call the function mysite.views.article_detail(request, '2005', '05', '39323').

http://www.djangoproject.com/documentation/overview/

これに近いような感じで、あるパターンとURLをマッピングしちゃいたいなと。
で、このURLConfのようにincludeも出来ると尚Goodなんですけどネ。

つまりユースケース毎くらいのある程度大きな粒度で、URL設計の結果をあるクラスに全部
おしこんでおくようなクラスです。これで詳細設計から実装まで比較的マッピングしやすくなります。

まだアイデアが固まっていませんが、開発branchなどでアイデア固めて、
本流へはそれからですね。
とにもかくにも機能追加は慎重にしたいのでどのタイミングでいつ入れるかは検討してみるべきですね。