元スレ[PHP][フレームワーク]CodeIgniterスレ
php覧 / PC版 / みんなの評価 : ○
前へ
751 = :
smartyをAjaxライブラリに対する回答だと思うのはさすがに・・・
752 = :
>>750
テンプレートエンジンを使うとすればどんなのがいいのでしょう？
↓
使わないのがいいでしょう
↓
客からの指示で、smarty必須ってなってる ←意味不明
自分で全部やれるなら楽だよな ←意味不明
(これから採用する人の話であってお前の客の話なんて知ったこっちゃない)
753 = :
頭が悪いのがいるな。
754 = :
わざわざ蒸し返すなや
誰が正当かなんてどうでもええねん
755 = 743 :
要するにテンプレートエンジンは不要なのですね。
AjaxのほうはjQueryが軽量コンパクトを売りにしてて伸び盛りのようです。
同じく軽量コンパクトを売りにしてるCIとはベストマッチじゃないでしょうか。
756 = :
必要かどうかは人それぞれだろ。
757 = :
軽量コンパクトがいいのか高機能がいいのかも提示せずに
相性云々言われても困るんだけど
ぶっちゃけAjaxライブラリにとってはサーバサイドのアプリケションが
何で書かれてようが知ったこっちゃ無いんだし相性もクソも何もない
758 = :
jQueryは軽量でもコンパクトでもない。
ありがちな操作を、最小のコード量で書く事に特化していて、かつ習得しやすいので普及率が高いだけ。
（そういう意味では、設計思想がPHPに近いのかもな、今思いついたが）
だから、jQueryに「できないこと」に手を出そうとすると非常に面倒になる。
それと、JavaScriptライブラリが軽量でコンパクトである事と、PHPフレームワークが軽量でコンパクトである事の関連性が良く分からない。
軽量フレームワークと軽量JSライブラリで、なんで「相性が良い」という結論になるんだ？
相性が悪いと言ってるわけじゃなく、単に論理展開、関係性が良く分からない。
つうか、ざっと簡単なアプリなり小物ライブラリでも作ってみりゃいいだろ。
机上の空論で初心者がライブラリの良し悪しを判別できるわけがない。
759 = :
なんだか、ケチつけたいだけの輩が巣食ってるらしい。
760 = :
そうだねjQueryがいいねとか嘘ついても仕方ないだろ
駄目なものは駄目と言うしかない
761 = :
駄目なんて誰も書いてないだろ。
わけのわからん基準で良い悪いを決める話じゃないってことだろ？
あれだ、本質を理解した上で用途に合わせて判断しろっていう、
当たり前のことを行ってるだけだ。
762 :
なるほど、jQueryはダメなのか。
どこがどうダメなんですか？
本質を理解した上で用途に合わせて判断ですか。
ご自身は本質を理解して判断されているのですね。すばらしい。
私には何が本質で何を基準に判断したらいいか皆目見当がつかないのですが
どんなところに注目すれば、本質を理解できるのでしょうか？
判断の基準は、例えばどんなところにおかれているのでしょうか？
763 = :
764 = :
jQueryでいいと思うよ。
というか、prototype.jsとの2択しか無い気がするが。
勉強するんだったら、このどっちかにしとくべき。
結局は、オープン系は何を使うにも主流どこに乗っとかないと
後々面倒だよ。スクラッチで作れるだけの力が無いのであれば。
767 = :
>762
> どんなところに注目すれば、本質を理解できるのでしょうか？
何かができるものは、絶対に何かを犠牲にしている、という点。
俺の書き込みが「jQueryはダメ」に見えたのなら、それはお前の経験不足。俺はjQuery信者だからな。
あと、理解したいならガタガタ抜かさずコード書け。
protojsとjQueryは併用できるしどっちかを選ぶようなものじゃないが、単独で込み入ったものを作るならprotojsが圧倒的に強い。
ただし>758でも書いたように、8割方のケースではjQueryのほうが圧倒的に早く作れる。
つまりどっちが向いているかは、どこまでをJSで処理し、どこからをサーバーサイドで処理するかによる。
768 = :
769 = 762 :
>>767
よくわかりました。ありがとうございます。
八割方のケースでjQueryが早くできること、
込み入ったことはprotojsが向いていることがわかって助かりました。
まあ、GoogleがjQueryを採用しているらしいので、
できないことというのも相当特殊なものかもしれません。
あと、その、サーバサイドでやることが、CIで補完しやすいとは限らないということですね。
770 = :
>>767
この手のが一番疲れる。ある程度はできるから。
771 = :
>>768
CIではGETを使えるので、そこを問題にしていたとは気づきませんでした。
デフォルトではセキュリティ上の理由から使えないようにしてあると
初期設定のチュートリアルにかかれてます。
773 = :
CIのGETの話題が出たので便乗させていただきます。
CodeIgniterの検索ページで、ページ送りするとき、検索条件をどうやって次のページに持っていってますか？
＝PCサイトと携帯サイトの違いをうまく処理したいです。
（携帯サイトは作ったことがないので、これからチャレンジすることになります。）
・日本のガラパゴス携帯のサイトは、基本的にクッキー無しという前提で作る。
・ページ間の遷移で、何らかの方法でセッションIDを持たせる。
・セッションIDに基づいて、サーバー側でセッション情報を保持しておき、セッション情報の中に検索条件を持たせておく。
こんな感じでOKでしょうか？
それで問題は、CIでセッションIDをどこに持たせるのか？
(1) POSTの場合
・デフォルトのCI設定で問題なし
(2) GETの場合
(2-1)・GETをOKの設定に変更する。 →これだとCIのURLヘルパーが使えなくて嬉しくない？
(2-2)・base64方式で、検索条件をエンコードして、URLのセグメントに無理やり埋め込む →URLに使える文字列長は上限があるので限度がある。
http://sourceforge.jp/projects/codeigniter/lists/archive/users/2009-March/001786.html
http://support.microsoft.com/default.aspx?scid=kb;ja;208427
GET メソッドを使用する場合、最大文字数は 2,083 文字に制限されます (実際のパスも含めた文字数)。
(2-3)・hookを使って、GETをPOSTに入れてしまう。→何かセキュリティーを考慮しなきゃいけない？＝独自のバリデーターを用意するとか？
http://www.ryuzee.com/contents/blog/734
今のところ(2-2)で対応できていますが、検索条件が多くなったらどうしよう…＞＜
774 = :
自己解決しました。
＝CI1.7.2のマニュアルに説明がありました。
http://codeigniter.jp/user_guide_ja/database/active_record.html#chaining
メソッドの連結を使えば、複数のメソッドをつなぐのがシンプルになります。
Note: メソッドの連結はPHP5 でのみ動作します。
CIは、PHP5とPHP4の違いを吸収するような便利な機能が提供されてますね。
http://codeigniter.jp/user_guide_ja/helpers/compatibility_helper.html
互換性ヘルパファイルには、PHP 5でしか実装されていないネイティブな関数と定数を、PHP 4でも実行できるものが含まれています。
これを使うことでPHP 4にしか対応していないサーバー上のアプリケーションでも、PHP 5のネイティブ関数を使うことができるようになります。
WebサーバがPHP4だから助かるな～
776 = :
>>741
CIには簡易のテンプレート機能が用意されてるから、それ使ってみれば？
http://codeigniter.jp/user_guide_ja/libraries/parser.html
テンプレートパーサクラスを使うと、ビューファイルに含まれる擬似変数を解析できます。
ビューページで純粋なPHPを使う方が少し早いので、CodeIgniterでは、このクラスを必ずしも 必要としません。しかし、PHPのコードで混乱してしまうデザイナーと一緒に仕事をしている場合、開発者の中には、テンプレートエンジンを使用したい人もいると思います。
ドリームウィーバーでHTMLが崩れなければ、Smartyは要らないよ(^^)v
777 = :
GET使えないとか不便なんだよな。
別に禁止にしなくても・・・。
778 :
>>777
デフォルトでオフなだけで禁止はされてないよ？
オフのままでもセグメントで指定できるから不便もないと思うけど。
779 = :
?guid=onさえなければ、良い設計だと思うよ…
PC版のみのサイトなら安心して使える。
今、携帯対応するのにindex.phpの冒頭で$_GET['guid']がセットされていたらunsetする処理を
足して使ってる。我ながら情けないけど、他にうまい手段が見つからない。
781 = :
RewriteRule ^(.*)$ ./index.php/$1 [PT,L]
これでどうだろ
784 = :
http://hero-kick.com/linux/entry-738.html
785 = :
>>784
ありがとうございます。
blog を参考に
RewriteEngine On
RewriteBase /
RewriteCond $1 !^(index\.php|images|robots\.txt)
#RewriteRule ^(.*)$ ./index.php?/$1 [L]
RewriteRule ^(.*)$ /index.php?/$1 [L]
としたのですが、 /index.php?/ の ? があるためか
「Disallowed key characters in global data.」が出ます。
? を外すと、やはり「No input file specified. 」に…。
786 = :
「Disallowed key characters in global data.」でいろいろググって
http://forum.kohanaphp.com/comments.php?DiscussionID=1723
を見つけました。
RewriteEngine On
RewriteBase /
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.+)$ /index.php?kohana_uri=$1 [L]
で一部表示！
「一部表示」というのは CSS や JavaScript のパスが解釈できていないため
デザインなどがガタガタなのです。とはいえ一歩前進です。
RewriteCond などを見直してみたいと思います。
いろいろとアドバイスをくれた皆様、本当にありがとうございます。
mod_rewrite は苦手なので試行錯誤をしていますので、
もし、こうだよ、とあれば引き続きよろしくお願いいたします。
790 = :
>>789
普通にURLエンコードじゃなんでダメなの？
検索条件の保持は、検索条件内容をDBにぶちこんで、そのIDを連れ回す方がしっくり来ると思う。
CIのフォーラムでもそんな感じだったと思った。
797 = :
>>793
$config['charset'] = 'iso-2022-jp';
$subject = mb_convert_encoding($subject, 'iso-2022-jp', 'utf-8');
$this->email->subject($subject);
$message = mb_convert_encoding($message, 'iso-2022-jp', 'utf-8');
$this->email->message($message);
$this->email->send();
で大丈夫だよ。
798 = :
>>797
おいおい。Subjectそのままで送るのか？
MIMEエンコードしろよ
799 = :
>>798
と思う前にやってみろ。
800 = :
>>799
ﾊｱ?
既にやってんだが
無知は黙ってろｋｓ
みんなの評価 : ○
php一覧へ類似してるかもしれないスレッド
- [PHP][フレームワーク]CodeIgniter Part2 (983) - [86%] - 2015/4/7 12:46
- 【PHP】フレームワークPharonスレ (306) - [60%] - 2022/10/10 20:00
- [PHPフレームワーク]Laravel (995) - [53%] - 2017/7/22 11:45
- 【PHP】PHPフレームワーク総合スレ14 (1001) - [50%] - 2010/12/11 10:32
- 【PHP】PHPフレームワーク総合スレ15 (989) - [50%] - 2013/9/27 6:00 △
- 【PHP】フレームワークMapleに舌鼓 (470) - [48%] - 2017/12/31 9:31
- 2ch有志がPHPフレームワークを作るスレ (81) - [45%] - 2019/5/9 7:46
トップメニューへ / →のくす牧場書庫について