なんとなく記録として残しておきます。
- サイトの部品として利用するBlogという点では，すでに今のCOREBlogは行き詰まっている
- 見栄えのカスタマイズやモジュールの設置なんかは，Zopeの初学者にとっては割と分かりやすい作りになっている。始めるのにも，モチベーションが持続する範囲で続けるにも，必要なケーススタディが比較的少なくて済む
- が，反面，それ以上高級な事をしようと思うと敷居が高い印象がある
- Hook Method + Plugin Productというヘンな思想を押し付けても，発展性がない
- 私は楽しいからいいけど，発展性のない事をお願いするのは，他の方にはとても失礼だ。。。
- 上記の事は生Zope全般にいえることかも
- そろそろ，いまの機能を別のフレームワークに乗っける事を考えてもよいのではないか
で。
- Zope/Python的な文脈で再利用可能な部品を作れる，という点では，CMFはそこそこ優れている
- CMFの上にポータルサイト(?)作成のためのフレームワークを乗っけたPloneはまあよくできている
- いろんな種類のオブジェクトがいろんな階層に入り乱れても，体裁が崩れないように作れるし
- ツールとかワークフローという仕組みを使って追加機能を実装する，みたいな方法論は今風だし，応用範囲が広いし，イケていると思う
- 反面，ケーススタディが増える。たくさんお勉強をしないとならない
- 開発速度，プレゼンスの問題
- 開発速度をあげるためにはやはりフレームワークを使った方がいい
- 世界的に見て，Zopeベースのオープンソースプロダクトを作った結果として得られる「プレゼンス」について考えると，どうも「素のZope Product <<<< Plone対応Product」のようである
- Zope Magとか最近Ploneのことばっかだし
- 「プレゼンスの増大」は，オープンソースソフトの開発者が得ることができる最大の利益である(と，私は思う)。その他の細かい事は後からついてくる(私がまさにそういう体験をしてます:-))。
- だいたいなんでPloneにまともなBlogプロダクトがないんだよ(--;
つーかね，今後Webサービスが複雑になってゆくと，粒度が低くて，連携しやすいような仕様を持ったオブジェクトを沢山種類作って，オブジェクト間連携させないとやってらんないと思うんですけど。沢山予算がついたプロジェクトってわけではないだろうし。ひも付きのプロジェクトだと，自由が効かない，つー面もあるよな。
というようなことを，まあここ最近考えているんですね。
