2018.07.01

hanaCMSのロジックをドキュメントルート以外で利用できるように調整

ユニクリエイトの自社開発CMS「hanaCMS」が更に使いやすくなりました。ドキュメントルート以上の階層にシステムロジックを隔離できる様になりました。

ドキュメントルートより上にシステムファイルを置くべき

ドキュメントルートってご存知ですか？apacheの設定でバーチャルドメインを設定する場合も然り、公開ディレクトリにシステムのロジックファイルを置くなという要望により、hanaCMSもそうゆう風に対応。
そもそもhanaCMSの場合は設定なんてほぼ不要なので、対応も簡単だったわけですが。ただ、ルート上ディレクトリへ設置する試験をしていなかったので対応していなかった部分でエラーが出ることにはなった。しかし、自身で一から作成したプログラムなので対応も早い！
20180627に対応完了。

そもそもdocRootにPHPファイルを置かない理由は。。。

はっきり言って分からないです。。。完全に勉強不足だと思います。要は、設定ファイルや穴を見つけ易くなりそうなサーバー情報を間違っても教えてしまうようなプログラムにはするなという意味だと思う。
しかし、、、大体index.phpなんかで結局php実行してたら意味はあまりない気もする。直接ファイルを実行されるような環境にはするなという意味なのだと思う。

hanaCMSの変更点

変更箇所いずれもファイルパス関連。
  • index.phpのディレクトリで手抜きをしていた部分。いわゆるconfigにあたる部分。
  • 管理画面のRDB木構造のビューファイル読み込み用の、ローカルパス生成部分。
  • config.phpを別に用意して、DB設定の情報をドキュメントルート以上へ隔離。
それだけです。これでsqliteもシステム部分も好きなディレクトリに設置しても相対的にローカルパスを生成でき、簡単に設置できるように対応しました。※sqliteはただ使っているだけなのでMysqlの場合は関係ありません。

hanaCMSの高速性能を再認識

仕事でcakePHPだったり誰かが作ったCMSだったりを触ることが多いのですが、やはり簡潔かつ高速で使いまわしも簡単なhanaCMSは優れているなぁと我ながらに実感しました。というか、cakePHPだったらCMSではなくて、フレームワークという類ですが、hanaCMSはzendとcakeに影響を受けたフレームワークが基盤なので自分的にはやっぱりコレがいいです。ロジックとビューの分離とかそんなの当たり前として、いかに問題点や修正箇所を早く特定できるか。いかに早く対応できるかを突き詰めてきた苦労の結果かな？と自分を褒めてみたり。

何ですか。。。コレ！？実は知ってる

世の中には色々なCMSが存在して、依頼であれば、変であってもなるべく手を加えず拡張するってのは色々勉強になったりもする。けど、辛い。MVCを使いまくってきた自分としては、本当に辛い。でも分かる。昔、興味本位で作成したプロトタイプのCMSに近かったりする。 コントローラとビュー、モデルの用途がイマイチ理解できていなくて、しまいにはコントローラいらない！なんて思ってたこともあった。だからビューでよくね？って事でビューにロジックを書きまくって再利用不可能な状態になってしまったりするのも凄く分かります。
なるべく早く切替える方が今後の事も考慮して最善だと思う。

MVCの考え方

Mはモデルの意味で、データを読み込んだり整形するclass。
Cはコントローラで、分岐などの大まかな処理を書き、見てすぐ分かるような完結なものが理想的。
Vはビューで、見た目のソースを作る部分。再利用や入れ子構造を表現できる設計がベストだと思う。
じゃあMCVじゃないか！？という方へ。私は正確な順番は分からないです。検索をしてもMVC,CMV,MCVなどいやCMVは聞いたことはないかも。。。色々あるので何が正解なのかは分からないです。また。MCVだけでフレームワークができているわけでもないです。
webサイトで利用する場合は、urlをパースしたりルーティングしたりしたあと、それに併せてコントローラーを読み込み、対応するアクション(メソッド)を実行し、その中でモデルを使ってデータを整理した後、ビューにデータを引き渡す。で、ビューをrenderという感じです。
フォーム系の処理があった場合はどこにロジックを書くか。自分の場合は大体、データを受ける、データをサニタイズするバリデートするなどをほとんど全てモデルに書きます。何かと便利ですし一年後忘れた頃に読みやすいうこと。ポストがある無いの判定さえモデルに書く。するとコントローラーは、model->save()だけで引数さえ書かなくてよいので非常にシンプルになります。さらにViewをモデルに渡してしまうのもありだと思っています。エラーの結果は結局ビューに渡す訳ですし。
何にしても、クラス同士のデータのやりとりを一ヶ所にまとめて、ルールを決めておかなければMV形式を使う意味は無いと思います。