CushyCMSがその機能をどのように実装しているかを誰かが説明できるかどうか興味があります。私が言及しているのは、htmlにクラスを追加することです<div class="cms-editable"></div>
。たとえば、そのdivを自動的に編集可能にして、コンテンツをデータベースに保存します。彼らはパーサーを使用してファイルを書き込みますか?彼らがデータをデータベースに保存しているとは思いません。
1 に答える
CushyはFTPベースです。つまり、ファイル構造に直接作用します。CushyのWebサイトにログインした後でWebサイトを表示すると、編集中のページを取得してクラスファイルが存在する場所を検査し、これを編集可能なアイテムにするのは、このWebサイトインターフェイスです。入力したFTPクレデンシャルを使用して、FTPプロトコルを介して電話をかけ、Webサイトのページを取得します。また、domを解析し、クラス名「cms-editable」をチェックし、インストール後のいくつかの構成手順の後で、このコンテンツをHTMLエディターで編集可能にします。変更を加えて保存すると、FTP経由で編集可能として定義したコンテンツ領域が直接変更されます。FTPプロトコルとDOM解析のためにこれを実現するために、サーバー側の言語には多くのツールがあります。
CushyCMSの良いところ
- 静的なWebサイトで非常に簡単に機能するため、設計者が設定できます。
CushyCMSの悪い点
- クライアントがページを直接編集していて、偶発的な構文エラーでWebサイトを簡単に壊してしまうため、動的なWebサイトにとってはひどいものです。一般に、MVCスタイルおよびWebプログラミングには適合しません。
- 最初にファイルで直接編集できるようにアイテムを設定する必要があるため、セットアップ後に管理が多すぎます。次に、そのインターフェイスを介してアクセス許可を与える必要があります。テンプレート化されたページが再利用されている場合にこれを行うことを想像してみてください。基本的にはできません。
- 実際には編集対象のソースファイルであるため、異なるユーザーが同時に異なる部分で編集している同じファイルを処理することはできません。ここで、誰かが編集した部分だけを保存していると考えて何かを保存し、ドキュメント全体を保存しただけではないことに気付かない場合に、上書きが問題になります。
私の答えの背景を説明するために、クラウドベースでCushyとはまったく異なる方法で構築されたCMSツールを作成しました。これは、フィードベースのアプローチがはるかに適切な場合、FTPとしての開発者にとっては大きな制限であるためです。また、自分のものを編集するために別のWebサイトにログインしなければならないのは面倒です。実際、HTML5クライアント側の編集機能とクロスドメイン通信用のpostMessageがあるのに、なぜバックオフィスさえあるのでしょうか。私のプロフィールには、このアプローチの詳細があります。