modxcms-jp / evolution-jp

https://modx.jp/
32 stars 25 forks source link

リソース制御用の新しいAPI #116

Open soushi opened 9 years ago

soushi commented 9 years ago

スニペットやプラグイン開発者が簡単にリソースを制御できるようなAPIを考えています。 使い方としては次の通りです。

・リソースの新規作成 $rs = new Document(); //リソースオブジェクト作成 $rs->set('pagetitle','新ページ'); //タイトル設定 $rs->set('content','ほげほげ'); //本文設定 $id = $rs->save(); //リソース保存 $idにはリソース保存時に設定されたリソースIDが入る

・既存リソースを削除

$rs = new Document(5); //id指定で既存リソース情報を読み込み $rs->delete(); //該当リソース削除

叩きみたいなソースは作成しているので後でコミットします。

以下は未実装機能一覧です。 全部は実装しないかも。

・グループ情報の参照と保存 ・リソースを操作しているユーザの設定 ・set()設定時の入力値チェック ・更新対象テーブルのカラム情報をクラスから外だし(別のAPIを作った時に共用化できる) ・入力値チェックメソッドの外だし(別のAPIを作った時に共用化できる) ・下書きに対しての保存、読み込み

終わったものはこちら。

・テンプレート変数の参照と保存 ・エラーメッセージ通知 ・リソースの完全削除

soushi commented 8 years ago

DocumentAPIの基底クラスとしてElementBaseを作成しました。 ElementBaseには主に履歴管理機能を付けようと思っています。 DocumentAPIでうまく動けば将来的にはChunkAPIやTemplateAPIを作る時に楽かなという目論見も。 あと履歴は複数残せるように考えているので、下書き機能にも使えたらと思っています。

なお、実験的な改修として別ブランチ(dev_element_manage)で作っているので、途中でうまくいかないと思ったらそっと消す可能性もあります…。

Fiberalph commented 8 years ago

チャンクやテンプレートなどのエレメントにも履歴管理機能はぜひ欲しいところですね!

enogu commented 7 years ago

履歴管理機能については REVISIONクラス(manager/includes/extenders/ex_revision.php) に基礎的なAPIを一元的に集約してしまったほうがあとあとデータベーススキーマの細工がしやすいかもしれません。

コアからは現状loadExtensionしてしまえば $modx->revision ですぐアクセスできるオブジェクトなのでプラグインなどでいじりやすいですし、DocmentAPIも内部的に$modxオブジェクトを注入する仕組みですから委譲やラッパーの用意はそれほど混乱なくできるように見受けられます。 うまく行きそうかどうかパッチを用意してみようと思います。

追記(2017/04/17) 上記の件についてsoushiさんと相談した結果、以下のような課題があることからElementBaseはそれはそれで必要であるという結論に至りました。 ・site_revisionテーブルは文書に限らずスニペットやチャンクなどの履歴管理を考慮した構造になっているにもかかわらず、現状のREVISIONクラスは文書の下書き管理を前提とした部分が多いため、履歴管理のベースとして使用するには冗長である。 ・将来的にリソースの編集処理の実装をDocumentParserから分離したい。下書きに関係した処理も複数個所に分散しているためなるべく集約したい。