日本のYiiユーザーいますか？
英語で会話しているかもしれないですが、日本だけPOSTないのは寂しいので書き込んでおきます。
自分はシステム屋の専門PGではなくてサービス側でPHPコード書いてる人間なので
細かい発注システムとかは自分には縁のない世界ですが
サーバーを借りてCMS系の物を作るような向きには、Yiiは凄い良いと思うんですけどどうでしょう？
特に、コンテンツサービス系だと、サイトのレスポンスが少しでも遅いと
ユーザーは見る気無くしちゃうし、CMS系ではキャッシュ使えない部分も多いと思うので、
日本語では情報少ないですが、Yiiが最適な選択肢になるのでは、と思ってます。
自分は今、Yiiでブログを試しに作っている所です 
yii触り始めました。
今まではCodeIgniter,ちいたんとかじって来ましたが、yiiは良さそうです。一番統合されている感じです。
ブログを作成されているとのことですが、yii-1.0.1でサンプルblogが同梱されましたね。このような小さいけど機能が充分なアプリを解読することが習得の一番の早道と思うので、中を覗いてみるつもりです。
覗いてみたところ、以下のような記事を投稿しました。
http://www.yiiframew…msg2361#msg2361
ところで、日本ユーザ会が欲しいですよね。そこで、先走って名前を考えてみましたが"いーじゃん: YII users group JApaN"というのはどうでしょうか？
ちょっと触ってなかったら既にBlogサンプル配布されてたんですね
しかもすでにカレンダーコンポーネントを作ってる人が居るとは…
日本ユーザー会いいですね。
自分もアプリで参加出来るように頑張ります
Quote
しかもすでにカレンダーコンポーネントを作ってる人が居るとは…
すみません、カレンダーコンポーネントと呼べるほどのものでは無いです。表示だけができる、なんちゃってカレンダーコンポーネントです。本来はブログの投稿日のハイライト、前後の月の移動等々の機能があるべきでしょうが、どのようにwidgetを組み込むのかが見たかったのでquick hackしました。
Quote
自分もアプリで参加出来るように頑張ります
yiiは直感的に素晴らしいと思うので、今はユーザがほとんどいなくてもこれから増えると思います。その場合必要になりそうに思います。
Quote
Quote
自分もアプリで参加出来るように頑張ります
yiiは直感的に素晴らしいと思うので、今はユーザがほとんどいなくてもこれから増えると思います。その場合必要になりそうに思います。
自分一人では躊躇しますが、少なくともユーザが複数いるということでユーザ会を立ち上げたいと思います(って何をやるのかは未定ですが)。少なくともドメインが必要になるのではと思い、とりあえず上記提案のwww.yiijan.orgを取得しました。ただし残念なことにサーバ自体にphp5が入っておらず、肝心のyiiは今のところ動きません。
ﾉｼ
まだ、サブ的に調べている段階ですが・・・yiiにかなり興味を持っています。
最近はブログのコメントに少しずつyiiが出現するようになってきてますね。
これからが楽しみです。
こんにちは。
Quote
最近はブログのコメントに少しずつyiiが出現するようになってきてますね。
これからが楽しみです。
私はSymphony(くじけた)→CI→ちいたん(forkして両刀)→Yiiと変遷してきましたが、CIとYiiを比較してみたので参考まで。
こんにちは
ブログ参考になりました。
私は、ZendFrameworkでオレオレFWを作ったところなのですが、yiiのコンポーネントやウィジェットの扱いを参考にしてみたいと思っています。
どこかの記事でyiiとZFを連携させた例もあるようですし。
※ところで、RSS外してます？
Quote
ZF自体がFWですが、その上のオレオレFWということは私のCIたんのようなものでしょうか？ちなみにCIたん(http://choco-moca.pugpug.org/wp/?p=161)というのは、CIとちいたんを比較(http://mocapapa.press9.net/cieaoieaeo/)して、ちいたんのほうが記述量が少ないために、CIに薄皮をかぶせてほぼちいたん互換とするプロジェクトです。
// が、Yiiを知ってからは熱が冷めてきました。
Quote
ブログにはwpを使用していますが、RSSに関して特に意識していませんでした。見直してみると、RSS/Atomに関して全文配信、最新10件となっており、特に外しているようには見えませんでした。
似た感じだと思います。
ZF単独では、モデルの記述やフォームのハンドリングは個別対応になるんですが、自分が納品するタイプの製品は意外とワンパターンだったりするので、ある程度仕様を絞って再利用性を高めたようなFWレイヤーが必要かなということで自作してあります。
でもそれって、オレオレを作らずに、ZFはライブラリ的に使ってyii拡張のほうがスマートなんじゃないか？
というのが今の興味の中心にあります。
RSSですが、ブログのフッターのところに、「Entries (RSS)」ってありますよね。
そこがリンク切れ？っぽかったのですが、私の勘違いだったらすみません^^;
はじめまして。今週よりYiiをいじりはじめたものです。
mysqlの5.0.xを使っている環境下で、yiic shellでテーブルからモデルを生成する際に
"…This command is not supported in the prepared statement protocol yet…"
というエラーが発生しており、しばらくハマっていたのですが、
http://www.yiiframew…start.first-app
の末尾のコメントを見てようやく抜け出すことができました。MySQL+PDOがらみのPrepered Statementでのハマりパターン（5.1.x以降では修正されたバグ）にぶちあたっていたようです
（参考： http://forums.mysql…d.php?52,117710 ）
Quote
自分もアプリで参加出来るように頑張ります
新参者ですが、僕も何かお役に立てることがあればぜひ。
それでは、よろしくお願いいたします。
Quote
ZF単独では、モデルの記述やフォームのハンドリングは個別対応になるんですが、自分が納品するタイプの製品は意外とワンパターンだったりするので、ある程度仕様を絞って再利用性を高めたようなFWレイヤーが必要かなということで自作してあります。
でもそれって、オレオレを作らずに、ZFはライブラリ的に使ってyii拡張のほうがスマートなんじゃないか？
というのが今の興味の中心にあります。
なるほど、ZFは触ったことが無いのですが、どこまで絞り込むかの違いかもしれません。CIはあまり絞られておらず、何でもできる。一方Yiiは絞られており？定型的なコードが生成される。もっともCRUDロジックは誰が書いてもこうなるわけで、8〜9割方できているのを修正するほうが私には楽です。viewはいくらでも好みのものに変更可能ですから。
Quote
そこがリンク切れ？っぽかったのですが、私の勘違いだったらすみません^^;
おっしゃるとおりでした。RSSはあまり気にしていませんでしたが、修正しておきます。
http://choco-moca.pu…g/wp/?feed=rss2
手でこのようにやったら動いたので、機能はあるようです。
Quote
こんにちは。1.0.1が1月4日なので、皆新参者です! 
Quote
"…This command is not supported in the prepared statement protocol yet…"
というエラーが発生しており、しばらくハマっていたのですが、
http://www.yiiframew…start.first-app
の末尾のコメントを見てようやく抜け出すことができました。MySQL+PDOがらみのPrepered Statementでのハマりパターン（5.1.x以降では修正されたバグ）にぶちあたっていたようです
prepared statementを使用されているのですか。
Quote
Quote
自分もアプリで参加出来るように頑張ります
新参者ですが、僕も何かお役に立てることがあればぜひ。
それでは、よろしくお願いいたします。
ユーザ会はバーチャル(脳内にという意味 )にとどまっていますが、私はyiidocというプロジェクトに参加しました。ここで日本語訳を行っています。とりあえず、システムメッセージを日本語訳しました。これは2月1日リリース予定の1.0.2に含まれる予定です。皆さんの画面におかしなエラーメッセージが表示されないように、今のうちに見ておいてくださいね！
http://code.google.c…ages/ja/yii.php
ユーザ会としてはこのような活動もその一つかなと思っています。もちろんユーザ会員が日本語訳を義務付けられるわけではなく、ユーザ会も日本語訳も全てボランティア(自由意志)ベースですよね。
最近yii使い始めました。
現在frameworkに求めていることは、
・モバイル対応しやすいか
・パフォーマンス
です。symfonyはモバイル対応がしにくかったんですが、yiiはどうでしょうかね・・・。
ところで、なぜこんなにパフォーマンスに差がでるのでしょうか？
なにかコーディングするコツとかあるんですかね？
それもdocumentに乗せてほしいです。作ってるうちに遅くなりそうなんで・・・。
Quote
Quote
"…This command is not supported in the prepared statement protocol yet…"
というエラーが発生しており、しばらくハマっていたのですが、
http://www.yiiframew…start.first-app
の末尾のコメントを見てようやく抜け出すことができました。MySQL+PDOがらみのPrepered Statementでのハマりパターン（5.1.x以降では修正されたバグ）にぶちあたっていたようです
prepared statementを使用されているのですか。
自前のトレースも加えてソースコードを追いかけてみたところ、YiiのCDbCommandクラスでPDO::query()を実行している箇所：
http://www.google.co…ckage:yii&l=275
がエラー発生部分となっていました。
PDO::queryのソースコード
http://www.google.co…1.0.3.tgz&l=945
にあるコメントいわく、
/* {{{ proto object PDO::query(string sql [, PDOStatement::setFetchMode() args])
Prepare and execute $sql; returns the statement object for iteration */
ということなので、明示的にprepared statementを使っていない場合でもprepareは実行される…という仕組みのようです（…が、もしかして誤解しているかも）
Quote
僕も先ほどqiangに「プロジェクト参加希望」のメッセージを送りました。いろいろお手伝いしたいと思います！
では。
Quote
prepared statementが分かっていないのですが、これはYiiのバグではないということですね？
Quote
では。
ぜひよろしくおねがいします。
Quote
Quote
prepared statementが分かっていないのですが、これはYiiのバグではないということですね？
はい、Yiiのバグではないと思います。また実際のDB操作を行っているPDOについても、query()メソッドでprepareを実行すること自体は仕様である（少なくともコメントレベルでは明記されている）ため、PDOも無罪である、という結論になるかと。
ということで、
Quote
のURL内にあるリンクで言及されているMySQLのバグ（prepared statementで"show create table"など、いくつかのコマンドが実行できない）
http://bugs.mysql.com/bug.php?id=20665
に当たったものと考えています。（ちなみに上記で述べたように、この問題はMySQL5.1以降では修正済みのようです）
Yiiは正しくこの問題を認識しており、CDbConnection.phpの$emulatePrepare変数の説明
http://www.yiiframew…#emulatePrepare
で、
Quote
For some databases (such as MySQL), this may need to be set true so that PDO can emulate the prepare support to
bypass the buggy native prepare support. Note, this property is only effective for PHP 5.1.3 or above.
と、「MySQLなどではtrueにしておく必要があるかもよ」と言っていたりします。具体的な設定方法は
http://www.yiiframew…t.first-app#c35
にあるように、protected/config/main.phpの"db"設定の部分に、
'emulatePrepare' => true
を追加するという感じです。
ということで、すいません、横道ばかりで少々長くなりましたが ^^; とりあえず。
Quote
http://www.yiiframew…t.first-app#c35
にあるように、protected/config/main.phpの"db"設定の部分に、
'emulatePrepare' => true
を追加するという感じです。
なるほど、これはtrueに設定していましたが、意味がわからずやっていました。勉強になりました。
Quote
現在frameworkに求めていることは、
・モバイル対応しやすいか
・パフォーマンス
です。symfonyはモバイル対応がしにくかったんですが、yiiはどうでしょうかね・・・。
ところで、なぜこんなにパフォーマンスに差がでるのでしょうか？
なにかコーディングするコツとかあるんですかね？
それもdocumentに乗せてほしいです。作ってるうちに遅くなりそうなんで・・・。
ktai extensionの方ですね。はじめまして
次の1.0.3からは、コントローラアクション内で
$this->layout=false;でレイアウト適用無し（現在無効)が出来ます。
今のバージョンでも
$this->lyaout='docomo';とかでメインレイアウト毎変えられます。
ビューのレンダリングは、他のFWなどにあるように各アクションで
自動で呼ばれたりはせず、render()を呼ぶ必要があるので、
アクション毎に対応するのは簡単だと思いますがちょっと泥臭い
やりかたになってしまうので、フィルターやコンポーネントなんかを
上手く使えばもっと上手く（包括的に）出来そうに思いますが
携帯用で尚且つページ数が多いものを想定した事がないので
僕はまだそこまで深く追求してないです。
投稿されたデータの絵文字の方は、モデルに変換を入れてしまえば
保存時にフィルタを入れる事と、セレクト時にUserコンポーネントから
キャリアを判断して変換する事で結構簡単に出来るんじゃないかと思います。
メールの方はちょっと分かりませんが、保存しないモデルの作成でも
フィルタを入れるのは簡単だと思います。
パフォーマンスはAPCが有効にできればとても早いそうですが
これは、Yiiのコアクラスを一枚にまとめたファイルが予め用意
されていて、そのPHPコードをAPCにキャッシュさせる方法で
高速化を図っていて、YiiのアナウンスではCodeIgniterよりも
早いという事になってますね。