私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】Yii Framework
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
あ、あと、Yiiのバージョンも書いてない点だな。
Yiiスレでエラー切り分けを問いたいなら、そういうところをちゃんと書くべし。
Yiiスレでエラー切り分けを問いたいなら、そういうところをちゃんと書くべし。
>>603
助言のとおり
http://example.sakura.ne.jp/exmple.com/site/login
で見ると正しく表示されました。
原因はドメインでアクセスするときにあるようです。
http://example.com/site/login
このURLでアクセスするとInternal Server Errorになるので。
ドメインでアクセスするときに、htaccessがどう動くかもっと調べてみます。
Yiiが原因ではなさそうなので、退散します！
スレ汚し失礼しました！
助言のとおり
http://example.sakura.ne.jp/exmple.com/site/login
で見ると正しく表示されました。
原因はドメインでアクセスするときにあるようです。
http://example.com/site/login
このURLでアクセスするとInternal Server Errorになるので。
ドメインでアクセスするときに、htaccessがどう動くかもっと調べてみます。
Yiiが原因ではなさそうなので、退散します！
スレ汚し失礼しました！
別ドメインを建てていて
/home/ユーザ名/www/example.com
が別ドメインのdocルートだっていう情報を提供せずにいたのが痛いわけだが、
それはともかく、
http://example.com/site/loginでのそのInternal Server Errorは、単純に
.htaccessの
Rewritebaseが
/example.com
になっているからに過ぎないと思うね。
Rewritebaseは/（URLパスルート）じゃなきゃいけないでしょ。そういう場合は。
まあスレ汚しにスレ違いのレスをするのもなんだけどさ。
/home/ユーザ名/www/example.com
が別ドメインのdocルートだっていう情報を提供せずにいたのが痛いわけだが、
それはともかく、
http://example.com/site/loginでのそのInternal Server Errorは、単純に
.htaccessの
Rewritebaseが
/example.com
になっているからに過ぎないと思うね。
Rewritebaseは/（URLパスルート）じゃなきゃいけないでしょ。そういう場合は。
まあスレ汚しにスレ違いのレスをするのもなんだけどさ。
user-moduleを利用する際等、moduleに手を加える際に
皆さんは直接ファイルを編集していますか？
それとも別moduleを作成してuser-moduleをオーバーライド
してますか？
皆さんは直接ファイルを編集していますか？
それとも別moduleを作成してuser-moduleをオーバーライド
してますか？
自分はyii-userをお手本にして、新しくuserモジュールを作りました
多分yii-userをカスタマイズしていくとわかりますが、けっこう大変ですよ
多分yii-userをカスタマイズしていくとわかりますが、けっこう大変ですよ
うーん、moduleの全てをextendsするのは
難しいものですね
module内でextendsしたmodule名が呼ばれていたり
結局moduleを直に書き換えているのとあまり変わらないような
この辺のノウハウというかヒントになりそうな情報があったら
教えて頂けるとありがたいです
難しいものですね
module内でextendsしたmodule名が呼ばれていたり
結局moduleを直に書き換えているのとあまり変わらないような
この辺のノウハウというかヒントになりそうな情報があったら
教えて頂けるとありがたいです
>>617
困った部分を、もう少し具体的に教えてもらえます？
困った部分を、もう少し具体的に教えてもらえます？
>>618
yii-user moduleを利用してます。
modules/user/UserModule.phpをYii::importしてから、modules/user/UserextModule.phpで
extendsしました。
これだとURLでindex.php?r=userext/profileを開くとmodelでエラーが出ます。
Yii::app()->getModule('user')->tableUsersのobjectが存在しないということらしいのです。
Yii::app()->getModule('userext')->tableUsersと書き換えれば通りますが、
結局元のmodelを書き換えてしまうことになります。
何かやり方がマズいようでしたら、こうした場合の良い方法があればヒントを頂きたく。
yii-user moduleを利用してます。
modules/user/UserModule.phpをYii::importしてから、modules/user/UserextModule.phpで
extendsしました。
これだとURLでindex.php?r=userext/profileを開くとmodelでエラーが出ます。
Yii::app()->getModule('user')->tableUsersのobjectが存在しないということらしいのです。
Yii::app()->getModule('userext')->tableUsersと書き換えれば通りますが、
結局元のmodelを書き換えてしまうことになります。
何かやり方がマズいようでしたら、こうした場合の良い方法があればヒントを頂きたく。
protected/config/main.phpで
'modules' => array('user' => array('id' => 'userext'...ではダメですか？
'modules' => array('user' => array('id' => 'userext'...ではダメですか？
コアでないmoduleを元ファイルと別にわざわざextendするメリットが思い浮かばない。
自分の使いやすいように、moduleファイルを普通に修正すればよいと思う。俺はそうしてる。
自分の使いやすいように、moduleファイルを普通に修正すればよいと思う。俺はそうしてる。
経験談ですが、ターゲットが日本人向けのサイトなら
yii-userの特定のクラスをextendsしようが
ファイルの中身を直接修正しようが、リスクはかなり大きいと思いますよ？
あと、ファイルの中身を直接修正するということは
yii-userがバージョンアップしても
それを使えない、もしくはextendsするより修正のリスクが大幅に上がることを考慮しないといけませんよ
yii-userの特定のクラスをextendsしようが
ファイルの中身を直接修正しようが、リスクはかなり大きいと思いますよ？
あと、ファイルの中身を直接修正するということは
yii-userがバージョンアップしても
それを使えない、もしくはextendsするより修正のリスクが大幅に上がることを考慮しないといけませんよ
使い捨て、あるいはコードを貰ってその後は独自モジュールとして
自分が育てるという>>621な人も、>>612,>>622の考え方に立った上で
独自拡張していると考えたい。
とはいえ、結構ハードコーディングがあったりして>>617のように
＞結局moduleを直に書き換えているのとあまり変わらないような
ということがあるのもわかる。
というわけで俺的方針。
(1)extends基本。
(2)「moduleを直に書き換え」と同じ手間っぽくて、かつ２，３の修正で済むなら
直接書き換えて、diffの履歴をとっておく。
(3)出力系の修正なら、置換用のラッパー作ってそれで対応。
(4)かなり変更が必要で、それでもそのモジュールを使い切りたい（バージョンアップにも
対応したい）場合＝＞(a)対象モジュールのクラス名称を全部かえて（シェルスクリプトを書く）
その後(b)自分の拡張モジュールでその対象モジュールクラス名を使う。
(4)で対応が出来ないようなら、使うのやめる。そこまで拡張が難しいなら今後も悩まされるはず。
ところで、>>609さん。>>619のケースなら、>>620さんの指摘でいけるんじゃないだろうか。
loadUserメソッドがわざわざモデルの変更を想定しているんだから。
自分が育てるという>>621な人も、>>612,>>622の考え方に立った上で
独自拡張していると考えたい。
とはいえ、結構ハードコーディングがあったりして>>617のように
＞結局moduleを直に書き換えているのとあまり変わらないような
ということがあるのもわかる。
というわけで俺的方針。
(1)extends基本。
(2)「moduleを直に書き換え」と同じ手間っぽくて、かつ２，３の修正で済むなら
直接書き換えて、diffの履歴をとっておく。
(3)出力系の修正なら、置換用のラッパー作ってそれで対応。
(4)かなり変更が必要で、それでもそのモジュールを使い切りたい（バージョンアップにも
対応したい）場合＝＞(a)対象モジュールのクラス名称を全部かえて（シェルスクリプトを書く）
その後(b)自分の拡張モジュールでその対象モジュールクラス名を使う。
(4)で対応が出来ないようなら、使うのやめる。そこまで拡張が難しいなら今後も悩まされるはず。
ところで、>>609さん。>>619のケースなら、>>620さんの指摘でいけるんじゃないだろうか。
loadUserメソッドがわざわざモデルの変更を想定しているんだから。
>>620
試してみましたが、挙動が変わらなかったです。
元々yii-userが考慮していないpropertyなのかもしれません。
色々方法やサンプルを探してみましたが、
moduleのextendsに関するものはなかなか出てこないです。
Yiiで制作されているオープンソースソフトウェアで
modulesのextendsしているものがあるか探してみようと思います。
無ければ、
>>623のdiffで取るやり方が正道なのかもしれませんね。
yii-userはバージョンアップの頻繁なmoduleのため、
直接編集すると大変そうですが。
>>622
>yii-userの特定のクラスをextendsしようが
>ファイルの中身を直接修正しようが、リスクはかなり大きいと思いますよ？
これはそもそもyii-userが日本向けサイトに向いてない作りという意味ですか？
試してみましたが、挙動が変わらなかったです。
元々yii-userが考慮していないpropertyなのかもしれません。
色々方法やサンプルを探してみましたが、
moduleのextendsに関するものはなかなか出てこないです。
Yiiで制作されているオープンソースソフトウェアで
modulesのextendsしているものがあるか探してみようと思います。
無ければ、
>>623のdiffで取るやり方が正道なのかもしれませんね。
yii-userはバージョンアップの頻繁なmoduleのため、
直接編集すると大変そうですが。
>>622
>yii-userの特定のクラスをextendsしようが
>ファイルの中身を直接修正しようが、リスクはかなり大きいと思いますよ？
これはそもそもyii-userが日本向けサイトに向いてない作りという意味ですか？
>>624
class ProfileController extends Controller
public function loadUser()
{
if($this->_model===null)
{
if(Yii::app()->user->id)
$this->_model=Yii::app()->controller->module->user();
なんだから考慮してると思うんだけど。
class ProfileController extends Controller
public function loadUser()
{
if($this->_model===null)
{
if(Yii::app()->user->id)
$this->_model=Yii::app()->controller->module->user();
なんだから考慮してると思うんだけど。
ちなみにyii-userのmessagesのjaはここで入手できます
http://code.google.com/p/yii-user/source/browse/#svn%2Ftrunk%2Fmodules%2Fuser%2Fmessages%2Fja
オフィシャルからのDLでは現在r107までのリビジョンなので、jaファイルは入ってません
あとここで少しデモれますよ
http://yii-user.2mx.org/
ユーザー登録する際は、アクティベーションのメールはfalseになっているので
ユーザ登録の流れなども確認できます
ログインの際に「ユーザ名が正しくありません」とか
「パスワードが間違っています」とか出るのはかなり痛いですがｗ
http://code.google.com/p/yii-user/source/browse/#svn%2Ftrunk%2Fmodules%2Fuser%2Fmessages%2Fja
オフィシャルからのDLでは現在r107までのリビジョンなので、jaファイルは入ってません
あとここで少しデモれますよ
http://yii-user.2mx.org/
ユーザー登録する際は、アクティベーションのメールはfalseになっているので
ユーザ登録の流れなども確認できます
ログインの際に「ユーザ名が正しくありません」とか
「パスワードが間違っています」とか出るのはかなり痛いですがｗ
>>627
あんた誰よ
あんた誰よ
>>628
通りすがりのものです
通りすがりのものです
CListViewが勝手にjqueryとjquery BBQ（?）を<head>に書きこんでくれるんだけど、
これをやめさせる方法ない？
今は無理矢理extendsして、
public function registerClientScript() {}
と空のfunctionをoverrideした
これをやめさせる方法ない？
今は無理矢理extendsして、
public function registerClientScript() {}
と空のfunctionをoverrideした
>>625
確認の仕方が悪かったです。ありがとうございます。
idでmodule名を切り替え出来ました。
しかしmodelsやviewsを拡張していくことを考えるとやはり
moduleは直接編集していくのが本道なのかもという気がしてきました。
それを考えるとyii-userのprofilesの項目追加の仕組みがややこしいのも
CMSを提供するのと同時に、ソースを触らせない前提という意図もあるのかなと。
確認の仕方が悪かったです。ありがとうございます。
idでmodule名を切り替え出来ました。
しかしmodelsやviewsを拡張していくことを考えるとやはり
moduleは直接編集していくのが本道なのかもという気がしてきました。
それを考えるとyii-userのprofilesの項目追加の仕組みがややこしいのも
CMSを提供するのと同時に、ソースを触らせない前提という意図もあるのかなと。
>>631
CBaseListViewをextendsして独自に作っていく方法のほうがより好みのwidgetを作れます
jqueryとbbqをheadに貼り付けたくないだけなら、ここらへんを抜いたもんを上書きすればOK。まさにやってそうですけど
$cs=Yii::app()->getClientScript();
$cs->registerCoreScript('jquery');
$cs->registerCoreScript('bbq');
$cs->registerScriptFile($this->baseScriptUrl.'/jquery.yiilistview.js',CClientScript::POS_END);
$cs->registerScript(__CLASS__.'#'.$id,"jQuery('#$id').yiiListView($options);");
>>632
yii-userがどういうものを扱っているモジュールなのか考えれば
基本的な設定はconfig/main.phpで上書きするようにして
他は直接編集していく形をとるのがベストだと思います
あと、ビューはif文などに気を使いながら、直接編集していくものです。拡張もくそもない
でも前に言いましたが、yii-userは編集するリスクがかなりあるので、1から自分で作るほうが賢いやり方のように思います
CBaseListViewをextendsして独自に作っていく方法のほうがより好みのwidgetを作れます
jqueryとbbqをheadに貼り付けたくないだけなら、ここらへんを抜いたもんを上書きすればOK。まさにやってそうですけど
$cs=Yii::app()->getClientScript();
$cs->registerCoreScript('jquery');
$cs->registerCoreScript('bbq');
$cs->registerScriptFile($this->baseScriptUrl.'/jquery.yiilistview.js',CClientScript::POS_END);
$cs->registerScript(__CLASS__.'#'.$id,"jQuery('#$id').yiiListView($options);");
>>632
yii-userがどういうものを扱っているモジュールなのか考えれば
基本的な設定はconfig/main.phpで上書きするようにして
他は直接編集していく形をとるのがベストだと思います
あと、ビューはif文などに気を使いながら、直接編集していくものです。拡張もくそもない
でも前に言いましたが、yii-userは編集するリスクがかなりあるので、1から自分で作るほうが賢いやり方のように思います
ちょっと前ここで話題になってたデータベースマイグレーションの有用性をずっと考えてたけど、
以下のような話に対応出来るという利点が一番大きいのかな
たしかにソースでデータベースの構造も構成管理出来るというのは納得できる利点なのかも
>ソースコードについて昔の状況が呼び出せてたとしても、それに依存するデータベースの状況も再現できなければまったく意味がないのです。
>これを実現するためには、従来はDDLを記述したファイルを直接コミットして管理するしかありませんでした。
http://www.atmarkit.co.jp/fdb/single/08s_jiemamy/jiemamy1.html
以下のような話に対応出来るという利点が一番大きいのかな
たしかにソースでデータベースの構造も構成管理出来るというのは納得できる利点なのかも
>ソースコードについて昔の状況が呼び出せてたとしても、それに依存するデータベースの状況も再現できなければまったく意味がないのです。
>これを実現するためには、従来はDDLを記述したファイルを直接コミットして管理するしかありませんでした。
http://www.atmarkit.co.jp/fdb/single/08s_jiemamy/jiemamy1.html
>>636
うん。おもしろい記事でした。ありがとう。
うん。おもしろい記事でした。ありがとう。
Yiiのマニュアル、Cookieのことについて書かれてないんだな
Wikiでまとめられてたけど
Cookieってそんな重要とされてないのかね
Wikiでまとめられてたけど
Cookieってそんな重要とされてないのかね
需要あると思うけど、なぜかないよね
俺もガイドがないから、仕方なくソースから勉強した
俺もガイドがないから、仕方なくソースから勉強した
>>640
ビューに直接PHPコードを書く方法
http://www.yiiframework.com/forum/index.php?/topic/16737-form-input-default-value-overrides-model-value/
モデルをnewしたときにデフォルト値を入れておく方法
http://www.yiiframework.com/forum/index.php?/topic/11960-preferred-way-to-set-dynamic-default-values-in-a-cactiverecord-model/page__view__findpost__p__58656
ここらへんが参考になるんじゃないでしょうか
ビューに直接PHPコードを書く方法
http://www.yiiframework.com/forum/index.php?/topic/16737-form-input-default-value-overrides-model-value/
モデルをnewしたときにデフォルト値を入れておく方法
http://www.yiiframework.com/forum/index.php?/topic/11960-preferred-way-to-set-dynamic-default-values-in-a-cactiverecord-model/page__view__findpost__p__58656
ここらへんが参考になるんじゃないでしょうか
あ、あとちょっと前に話題になってたARの利点だけど、>>636のページのリンク先に以下のように記載があって、
まんまARの利点として言えるんじゃないかと思うんだがどうだろう
※記事の内容はARとは直接的に関係ない
http://objectclub.jp/community/XP-jp/xp_relate/evodb-jp
>データベースアクセスコードを明確に分離する
>データベースリファクタリングの影響を把握するためには、データベースがアプリケーションによってどのように使われているかを調べることが可能でなければならない。
>SQLがコード達の中に乱雑に散らばっているならば、調査は非常に困難になる。
>つまり、データベースがどこでどのように使用されているかを明らかにするために、明確なデータベースアクセス層を設けることが重要になる。
>データベースアクセス層を設ける際にはPofEAAの中からデータソースアーキテクチャパターンのどれかに従うことを勧める。
ちなみに上記で言及されているPofEAAにもARが紹介されている
http://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?ActiveRecord
業務系開発の中では意外と歴史があるらしく、ここら辺の書籍を読むことで経緯なんかも深く知ることが出来るのかもね
まんまARの利点として言えるんじゃないかと思うんだがどうだろう
※記事の内容はARとは直接的に関係ない
http://objectclub.jp/community/XP-jp/xp_relate/evodb-jp
>データベースアクセスコードを明確に分離する
>データベースリファクタリングの影響を把握するためには、データベースがアプリケーションによってどのように使われているかを調べることが可能でなければならない。
>SQLがコード達の中に乱雑に散らばっているならば、調査は非常に困難になる。
>つまり、データベースがどこでどのように使用されているかを明らかにするために、明確なデータベースアクセス層を設けることが重要になる。
>データベースアクセス層を設ける際にはPofEAAの中からデータソースアーキテクチャパターンのどれかに従うことを勧める。
ちなみに上記で言及されているPofEAAにもARが紹介されている
http://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?ActiveRecord
業務系開発の中では意外と歴史があるらしく、ここら辺の書籍を読むことで経緯なんかも深く知ることが出来るのかもね
$criteria->with = array('category2'=>array(
'select'=>'SUM(price) as price',
'group'=>'category1_id'
));
これでいけたりするんかいな？
'select'=>'SUM(price) as price',
'group'=>'category1_id'
));
これでいけたりするんかいな？
見た感じ無理そうですけどｗどうなんでしょう？
findAllBySql()で良いんじゃないですか？
findAllBySql()で良いんじゃないですか？
>>643
そもそもSQL自体こうだろ。
SELECT c1.id, max(c2.name), sum(c2.price)
FROM category1 c1
LEFT JOIN category2 c2 ON c1.id=c2.category1_id
GROUP BY c1.id
SQLよく知らないのにAR使うのは百害あって一利なしだからやめといた方がいい。
そもそもSQL自体こうだろ。
SELECT c1.id, max(c2.name), sum(c2.price)
FROM category1 c1
LEFT JOIN category2 c2 ON c1.id=c2.category1_id
GROUP BY c1.id
SQLよく知らないのにAR使うのは百害あって一利なしだからやめといた方がいい。
>>647
category2を外部結合してるから、c2.priceがnullだと、sum(c2.price)もnullになっちゃうよ？
category2を外部結合してるから、c2.priceがnullだと、sum(c2.price)もnullになっちゃうよ？
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
php スレッド一覧へ類似してるかもしれないスレッド
- 【PHP】Yii Framework Part 2 (182) - [72%] - 2019/5/9 7:45
- 【PHP】PEAR Part3 (703) - [41%] - 2022/10/30 21:15 ☆
- 【PHP】気軽にPHP質問スレ (1001) - [12%] - 2013/2/7 9:31
トップメニューへ / →のくす牧場書庫について