forked from modxcms-jp/evolution-jp
-
Notifications
You must be signed in to change notification settings - Fork 0
Home
yama edited this page Mar 8, 2012
·
21 revisions
Welcome to the evolution-jp wiki!
以下、1.0.7以降で検討したいメモ書き
- manager/includes/ はコア領域として分離し、ブラウザからアクセスできない領域に自由に移動できるものとする。できるだけコンパクトに整理された構成を保つ。
- manager/includes/ディレクトリの内容を整理。不要なファイルはほとんどないが、まとめられるものはまとめる
- ファイルマネージャーやリッチテキストエディタは基本的に外付けにすべき。どんなに多機能でも開発が止まったり差し替えがしづらいのは困る。内蔵の機能は最低限のシンプルなものがいい
- 軽量であることはキープする。現状、1.3MB程度のメモリで駆動する。他のCMSと比べて、ケタひとつ抜けるくらい軽量。これでもまだ改良の余地が多い
- テンプレート・チャンク・スニペット・プラグイン・メンバーアカウントなどは、画面に収まりきらないくらい増えても管理できるように考える必要がある
- テンプレートは入れ子で管理できるようにする
- リソース変数もテンプレート変数なみに入出力をカスタマイズできるようにする。ManagerManagerの考え方をヒントにし、コンテキストを自由に指定できるようにする。たとえばManagerManagerの場合、管理画面にアクセスした曜日などによって投稿画面のフィールド構成を変えるようなことができる。このような柔軟な使い方はRevoではできなくなっている
- 新規作成・移動・複写・削除・公開・非公開などの基本操作を管理画面全域に渡って充実。リソースエクスプローラとしての操作性を充実させる
- 複写先を選べるようにする
- documentParser内の関数構成をAPIと基本関数に分ける。基本関数は$modxクラスでなくてもかまわない。この点はRevoとは違う割りきった構成にする
- ブログを管理できるようにする
- エイリアスの管理を根本的に見直す。WordPressなど他CMSが、普通に設計していてもページ数の多さが障害にならないのは、カテゴリー管理が別になっているから。数万ページものページ数を持つサイトでも、カテゴリー数は数えられる程度で収まっているケースがほとんど。MODXの場合は、数万ページあれば数万ページぶんのエイリアス情報を管理するため、非常に効率が悪い。ドキュメントオブジェクトとして扱うべきではあるが、工夫が必要。isfolder属性を持つリソースのみをツリー管理できれば、格段にコンパクトに収まるはず。
- 管理画面の脆弱性対策をトークンチェック実装にする
- 管理画面のカスタマイズを自由にできるようにする
- Ditto感覚で使えるリスティングエンジンが必要。管理画面内で用いる
- ページキャッシュを任意のコンテキストごとに管理できるようにする(ページ単位・UA単位など)
- ページ数が増えても重くならないようにする
- バージョンが古くなったMooToolsをjQueryに差し替える
- HTMLとPHPが入り混じったコードをきれいに書き直す
- API をしっかり整備する
- 各部の仕様をできるだけRevoに合わせる
- テンプレートや拡張機能のインストールをWordPress並みに簡単にしたい
- システムアップデートを管理画面内から行なえるようにする
- イベント関係。メニューの $sitemenu・$resourcemenu にアクセスできるイベントなど
- PHxの機能を標準実装
- テンプレート・チャンク・スニペット・ユーザなどを階層管理できるようにする
- チャンクやスニペットにpub_date・unpub_dateを実装。できるだけdocumentObjectの構造に倣う
- エクスポート機能を充実させて、パブリッシュ感覚で本格的なサイトを出力できるようにする
- /manager/includes/ ディレクトリをmanager領域と分離(コア領域として明示する)