サンプルアプリケーションがドキュメントルート以外では動作しない件について
shuwat
ずっと時間が取れなかったのですが、最近また心新たにPieceを触り始めました。
新しいサンプルアプリをインストールしてみたのですが、ドキュメントルート以外にファイルを置くと動かなかったので、少し戸惑いました。
flowMappingsの設定を変え、appRootPathを設定してやると動くのですが、今度はタイトルが設定されなかったりで、なんだかしょん
ぼりな感じです。
もちろんドキュメントどおりにバーチャルサーバでも切って、Webサーバのドキュメントルートにインストールすればこういうことはないのでしょうが、と
りあえずPieceを触ってみたい、という向きにはこのあたりで敷居の高さを感じさせてしまうのでは・・・と危惧してしまいます。
ところで、1.3から導入されたflowMappingsは、どのようなメリットがあるのでしょうか？
ご存知の方教えてください。
よろしくお願いします。
katarou
On 12月11日, 午後7:22, shuwat <watanabe.shuns...@gmail.com> wrote:
> 皆様お久しぶりです、渡辺です。
>
> ずっと時間が取れなかったのですが、最近また心新たにPieceを触り始めました。
>
> 新しいサンプルアプリをインストールしてみたのですが、ドキュメントルート以外にファイルを置くと動かなかったので、少し戸惑いました。
>
> flowMappingsの設定を変え、appRootPathを設定してやると動くのですが、今度はタイトルが設定されなかったりで、なんだかしょん
> ぼりな感じです。
>
> もちろんドキュメントどおりにバーチャルサーバでも切って、Webサーバのドキュメントルートにインストールすればこういうことはないのでしょうが、と
> りあえずPieceを触ってみたい、という向きにはこのあたりで敷居の高さを感じさせてしまうのでは・・・と危惧してしまいます。
>
一部ルート固定になっている箇所があるみたいですね。
> ところで、1.3から導入されたflowMappingsは、どのようなメリットがあるのでしょうか？
> ご存知の方教えてください。
>
自分が感じたflowMappigngsは
1.複数フローを扱う場合、設定ファイルに記載することによりメンテナンスが行いやすい。
2.１と似てますが、分散開発を行う場合に説明が行いやすい。(configを見ればわかる）
3.アプリケーションディレクトリをたとえば/appから/applicationや,/foo/appに移行する場合、基本的にflowIDの変更だ
けでよい？
これはまだ未確認ですが、テストで変更してみたら問題なく動いているようなので、、
ただ、階層が変わった場合は、エントリポイントで相対パスでconfigの指定を行っている場合、その指定を変更する必要があります。
4.フローごとに排他モードと非排他モードの切り替えができる
これは試していないのでわかりませんが、業務アプリとかで便利そうです。
こんなところでしょうか？
設計意図と異なっていたら申し訳ないです＞久保さん
> よろしくお願いします。
shuwat
> 自分も最初ハマりました。自分は8080等の別ポートでサーバを立てて動かしてました。
> 一部ルート固定になっている箇所があるみたいですね。
80ポート以外で動かないなら、それはより起こりそうな条件ですね。
> 1.複数フローを扱う場合、設定ファイルに記載することによりメンテナンスが行いやすい。
> 2.１と似てますが、分散開発を行う場合に説明が行いやすい。(configを見ればわかる）
> 3.アプリケーションディレクトリをたとえば/appから/applicationや,/foo/appに移行する場合、基本的にflowIDの変更だ
> けでよい？
> これはまだ未確認ですが、テストで変更してみたら問題なく動いているようなので、、
> ただ、階層が変わった場合は、エントリポイントで相対パスでconfigの指定を行っている場合、その指定を変更する必要があります。
> 4.フローごとに排他モードと非排他モードの切り替えができる
> これは試していないのでわかりませんが、業務アプリとかで便利そうです。
3についてはわかりません。
自分でも触って実感してみようと思います。
ありがとうございました。
KUBO Atsuhiro
shuwat さんは書きました:
> 新しいサンプルアプリをインストールしてみたのですが、ドキュメントルート以外にファイルを置くと動かなかったので、少し戸惑いました。
>
> flowMappingsの設定を変え、appRootPathを設定してやると動くのですが、今度はタイトルが設定されなかったりで、なんだかしょん
> ぼりな感じです。
>
> もちろんドキュメントどおりにバーチャルサーバでも切って、Webサーバのドキュメントルートにインストールすればこういうことはないのでしょうが、と
> りあえずPieceを触ってみたい、という向きにはこのあたりで敷居の高さを感じさせてしまうのでは・・・と危惧してしまいます。
ご意見ありがとうございます。
こちらについてはドキュメントに「ドキュメントルートの設定が不可能な場合」
の項を追加しました。詳細は下記 URL を参照ください。
また、
* どこにどのようなディレクトリ構成で配置しても動くアプリケーションを
作るのは難しい
* 可能であったとしてもそのための設定を別途行わなければならない
* サンプルアプリケーションの配布目的にはプロモーションや動作確認だけ
でなく、推奨のディレクトリ構造や動作する最新のコードを参照可能にす
ることもある
といった理由により今のところプロダクトとしての対応は考えておりません。
katarou さんは書きました:
>> ところで、1.3から導入されたflowMappingsは、どのようなメリットがあるのでしょうか？
>> ご存知の方教えてください。
>>
> 自分が感じたflowMappigngsは
> 1.複数フローを扱う場合、設定ファイルに記載することによりメンテナンスが行いやすい。
> 2.１と似てますが、分散開発を行う場合に説明が行いやすい。(configを見ればわかる）
> 3.アプリケーションディレクトリをたとえば/appから/applicationや,/foo/appに移行する場合、基本的にflowIDの変更だ
> けでよい？
> これはまだ未確認ですが、テストで変更してみたら問題なく動いているようなので、、
> ただ、階層が変わった場合は、エントリポイントで相対パスでconfigの指定を行っている場合、その指定を変更する必要があります。
> 4.フローごとに排他モードと非排他モードの切り替えができる
> これは試していないのでわかりませんが、業務アプリとかで便利そうです。
>
> こんなところでしょうか？
> 設計意図と異なっていたら申し訳ないです＞久保さん
田川さん、フォローありがとうございます。
flowMappings の最大の目的は「階層構造サポートとより少ない設定」にあり
ます。下記はマニュアルからの引用です。
> ある程度大きなアプリケーションでは、情報へのパスに規律を与えるための命名規約とファイルの階層化は重要な要素です。これまでPiece_Unityでは部分的にしかそのような構造をサポートしていなかったため、ユーザが自前で階層構造をサポートする場合の設定量が多くなってい
ました。
>
> Piece_Unity 1.4.0で導入されたflowMappingsにより、フロー定義ファイル、アクションクラス、HTMLの階層構造がサポートされました。その結果、Piece_Unity設定ファイルによるアプリケーションワイドの設定量は若干増えたものの、下記の設定が不要になるため全体としての設
定量を大幅に少なくすることができるようになりました。
>
> * エントリポイントにおけるフローIDの指定
> * エントリポイントにおけるフローに対応するHTMLディレクトリの指定
> * フロー定義ファイルにおけるアクションクラスの明示的な指定
田川さんの書かれた内容については概ねそのとおりです。補足しますと、
> ただ、階層が変わった場合は、エントリポイントで相対パスでconfigの指定を行っている場合、その指定を変更する必要があります。
は設定ファイルで appRoot に絶対パスすることによって不要になります。
ただしポータビリティは失われます。
プロダクトのものは実際のアプリケーションのポータビリティを意識した設定
となっていますが、ひとつのファイルに抽出するなど改善の余地はあります。
以上、よろしくお願いいたします。
--
KUBO Atsuhiro e-mail: ku...@iteman.jp
KUBO Atsuhiro
shuwat さんは書きました:
>> 自分も最初ハマりました。自分は8080等の別ポートでサーバを立てて動かしてました。
>> 一部ルート固定になっている箇所があるみたいですね。
> 80ポート以外で動かないなら、それはより起こりそうな条件ですね。
念のためテストしましたが、当方の環境では 80 番ポート以外でも問題なく動
作しています。
おそらくディレクトリ構造が異なる場合の問題だと思いますが、その場合はド
キュメントを参考に試してみてください。
それでも動作しない場合は、不具合として詳細を報告していただけると助かり
katarou
すみません、自分の発言で誤解を招いてしまってたようで。
>> 自分も最初ハマりました。自分は8080等の別ポートでサーバを立てて動かしてました。
>> 一部ルート固定になっている箇所があるみたいですね。
> 80ポート以外で動かないなら、それはより起こりそうな条件ですね。
ドキュメントルート以外に配置してうまく動かなかったので、8080番でドキュメントルートを割り当てて動かしていました。
です。誤解を招くような発言をしてしまって申し訳ないです。8080番でドキュメントルート上で動かす分には問題はありませんでした。
あと、
>> ただ、階層が変わった場合は、エントリポイントで相対パスでconfigの指定を行っている場合、その指定を変更する必要があります。
>は設定ファイルで appRoot に絶対パスすることによって不要になります。
>ただしポータビリティは失われます。
エントリポイント（入り口phpファイル？）上でpiece_unityのインスタンスを作成するのにpiece-unity-config.yaml
の場所の指定が必要かと思いますが
（不要だったらすみません）
$base = '../webapp';
session_save_path ( "$base/sessions" );
$config = &new Piece_Unity_Config();
$unity = &new Piece_Unity("$base/config", "$base/cache", $config);
とエントリポイントに記載し動作させています。
フォルダ下位層が一つ下のフォルダに変更になった場合
$base = '../../webapp';
と書かないといけないと思っていました。間違っていたら申し訳ないです。
appRootは久保さんのおっしゃるとおりで、問題なく動作してます。（かなり楽になりました）
混乱させてしまい申し訳ありませんでした。
※なかなか表現するのは難しいですね^^;
On 12月19日, 午前1:51, KUBO Atsuhiro <k...@iteman.jp> wrote:
> 久保です。
>
> shuwat さんは書きました:
>
> >> 自分も最初ハマりました。自分は8080等の別ポートでサーバを立てて動かしてました。
> >> 一部ルート固定になっている箇所があるみたいですね。
> > 80ポート以外で動かないなら、それはより起こりそうな条件ですね。
>
> 念のためテストしましたが、当方の環境では 80 番ポート以外でも問題なく動
> 作しています。
> おそらくディレクトリ構造が異なる場合の問題だと思いますが、その場合はド
> キュメントを参考に試してみてください。
>
>
> それでも動作しない場合は、不具合として詳細を報告していただけると助かり
> ます。
>
> --
> KUBO Atsuhiro e-mail: k...@iteman.jp
shuwat
On 12月19日, 午前1:40, KUBO Atsuhiro <k...@iteman.jp> wrote:
> ご意見ありがとうございます。
> こちらについてはドキュメントに「ドキュメントルートの設定が不可能な場合」
> の項を追加しました。詳細は下記 URL を参照ください。
二点質問させてください。
一、Confiturator_Proxyプラグインの設定を削除するのはなぜでしょうか？
二、actionDirectory、cacheDirectory、configDirectoryの値にはappRootで指定された文字列がな
く、flowMappingsのurlの値にはappRootも含めたフルパスで記述がされているのはなぜでしょうか？
> flowMappings の最大の目的は「階層構造サポートとより少ない設定」にあり
> ます。下記はマニュアルからの引用です。
>
こちらもありがとうございます。
ファイルの階層化を試してみようと思います。
KUBO Atsuhiro
katarou さんは書きました:
>>> ただ、階層が変わった場合は、エントリポイントで相対パスでconfigの指定を行っている場合、その指定を変更する必要があります。
>> は設定ファイルで appRoot に絶対パスすることによって不要になります。
>> ただしポータビリティは失われます。
> については
> エントリポイント（入り口phpファイル？）上でpiece_unityのインスタンスを作成するのにpiece-unity-config.yaml
> の場所の指定が必要かと思いますが
> （不要だったらすみません）
>
> $base = '../webapp';
> session_save_path ( "$base/sessions" );
>
> $config = &new Piece_Unity_Config();
> $unity = &new Piece_Unity("$base/config", "$base/cache", $config);
>
> とエントリポイントに記載し動作させています。
>
> フォルダ下位層が一つ下のフォルダに変更になった場合
> $base = '../../webapp';
> と書かないといけないと思っていました。間違っていたら申し訳ないです。
サンプルアプリケーションをリファクタリングしてみました。
http://trac.piece-framework.com/piece-examples/browser/trunk/basics/web/htdocs/authenticate.php
http://trac.piece-framework.com/piece-examples/browser/trunk/basics/web/htdocs/index.php
http://trac.piece-framework.com/piece-examples/browser/trunk/basics/web/webapp/lib/prepare.php
このようにすることで変更が必要な箇所を、階層の深さに応じた prepare.php
へのパス、の 1 点にすることができます。
katarou
フォローいただき有難うございます。
なるほど、このようにすれば確かに１点の変更ですみますね。
気がつきませんでした。早速自分も変更してみます。
有難うございます。
On 12月21日, 午後1:05, KUBO Atsuhiro <k...@iteman.jp> wrote:
> 久保です。
>
> katarou さんは書きました:
>
>
>
>
>
> >>> ただ、階層が変わった場合は、エントリポイントで相対パスでconfigの指定を行っている場合、その指定を変更する必要があります。
> >> は設定ファイルで appRoot に絶対パスすることによって不要になります。
> >> ただしポータビリティは失われます。
> > については
> > エントリポイント（入り口phpファイル？）上でpiece_unityのインスタンスを作成するのにpiece-unity-config.yaml
> > の場所の指定が必要かと思いますが
> > （不要だったらすみません）
>
> > $base = '../webapp';
> > session_save_path ( "$base/sessions" );
>
> > $config = &new Piece_Unity_Config();
> > $unity = &new Piece_Unity("$base/config", "$base/cache", $config);
>
> > とエントリポイントに記載し動作させています。
>
> > フォルダ下位層が一つ下のフォルダに変更になった場合
> > $base = '../../webapp';
> > と書かないといけないと思っていました。間違っていたら申し訳ないです。
>
> サンプルアプリケーションをリファクタリングしてみました。
>
> このようにすることで変更が必要な箇所を、階層の深さに応じた prepare.php
> へのパス、の 1 点にすることができます。
>
> --
>
> - 引用テキストを表示 -
KUBO Atsuhiro
On 2007/12/20 18:24, shuwat wrote:
> 一、Confiturator_Proxyプラグインの設定を削除するのはなぜでしょうか？
Piece_Unity 1.4.0 現在の仕様では、Confiturator_Proxy プラグインの設定
ポイント proxyPath の値は、Piece_Unity_Context のメソッド
getBasePath()/getScriptName()/getAppRootPath() が返す値の先頭に付与さ
れる形で利用される一方、ビュー文字列や認証 URL などリダイレクション用
の URL においてはそれらから削除されるといった、正反対の動作を内包して
います。
リバースプロキシ使用時にバックエンドサーバに直接リクエストされた場合、
それらの URL は後者の動作によりフロントエンド URL からバックエンド URL
へ変換する必要があるため、proxyPath の値が機能することが求められますが、
リバースプロキシを使用しない場合は、そのような変換によってリダイレクシ
ョン用 URL がおかしくなります。Confiturator_Proxy プラグインの設定を削
除をするのは、そのような不要な変換を防ぐためです。
通常のアプリケーションにおいては、リバースプロキシを使用する場合としな
い場合は明白であり、Confiturator_Proxy プラグインについても同様です。
あくまでもサンプルアプリケーションという特殊な環境に起因する問題である
ことに注意してください。
この動作は今後のバージョンで変更するかもしれません。リダイレクション用
URL に指定する URL をバックエンド URL にすれば、このような問題がなくな
ると考えられるからです。
また、サンプルアプリケーションからのリバースプロキシ関連要素の削除も検
討したいと思います。
> 二、actionDirectory、cacheDirectory、configDirectoryの値にはappRootで指定された文字列がな
> く、flowMappingsのurlの値にはappRootも含めたフルパスで記述がされているのはなぜでしょうか？
実行環境のカレントディレクトリが appRoot で指定されたディレクトリに cd
されますので、actionDirectory/cacheDirectory/configDirectory にはその
ディレクトリからの相対パスが記述される必要があります。
一方 flowMappings の url は URL であるため、cd によるカレントディレク
トリの移動とは関係がありません。また、url にはフローの識別子としての役
割があるため、実際の相対 URL と一致する必要があります。