08/11/15 15:11:46
>>593
わかんね。
フラグじゃなくてカウンタにするってこと？
597:nobodyさん
08/11/15 16:06:02
大規模向けではなく一番スケールアウトしやすいFWは?
598:nobodyさん
08/11/15 16:34:55
スケールアウト考えたらモデルは自分で書かないときつくね？
599:nobodyさん
08/11/15 16:57:52
ちｒｙ
600:nobodyさん
08/11/15 17:24:52
>>595
deleted（datetime）がnullかどうか
601:nobodyさん
08/11/15 17:52:20
int型にして、0だと削除扱いにするのが妥当だろうな。PHPやPerlなら、ブーリアン評価でfalseが帰ってくるし。
602:nobodyさん
08/11/15 17:55:22
勝手に値はいるのはtimestampだけだっけ？
603:nobodyさん
08/11/15 18:02:15
>>602
NOT NULL にしておいて default を設定すれば入るだろ
604:nobodyさん
08/11/15 18:49:10
mysqlはデフォルト値に関数が使えない
605:nobodyさん
08/11/15 18:51:03
>>600
deletedってどういうこと？
606:nobodyさん
08/11/15 19:09:25
フィールド名じゃないの？
607:nobodyさん
08/11/15 19:12:51
ああそういうことか、関数かと思ったｗ
608:nobodyさん
08/11/15 19:13:24
nullだとインデックスが使われないから論理値のほうが良くない？
609:nobodyさん
08/11/15 19:27:12
nullかどうかで求めるのは本来正しく無いだろうね
削除された、と言う状態がシステム上にありうるならそれはnullで表現すべきじゃない
610:nobodyさん
08/11/15 19:54:48
というか、３値論理っての？ NULL を理解していないとか必要性を感じないとかの場合は、
全フィールド NOT NULL で作ってしまえと言いたい。
その方が何かとトラブルが少ないし、コーディングも楽だ。
テキストフィールド？ 空文字でも入れとけ。 数値？ 0が初期値だ。それで都合がわるけりゃ、
-999999999 が初期値だ、文句あるか、ってな感じで。
611:nobodyさん
08/11/15 22:00:11
>>608
MySQLならenum型でnullを使う分にはNULLでインデックスされると思うよ
他のDBでは知らない
612:nobodyさん
08/11/15 23:07:45
>>607
そう、カラム名。
id, created(datetime), updated(datetime), deleted(datime)を標準的に使用。
あるいは、statusとしてa)Activei)/Inactive、h)Hidden, b)Obsoleted D)deleted
とか詳しい状態が必要な時に使うとか。
613:595
08/11/15 23:12:27
いろいろやり方あるんすね。すごい勉強になった。
皆さん有り難うございます。
614:nobodyさん
08/11/15 23:21:42
論理だろうがなんだろうが、削除っていうからカッチリ噛み合わないと思うんだよね
実際問題何も消してないわけなんだし
だから、そういうのは無効化とか不活性化とか利用不可とか、そういう「状態」で呼ぶべきで
削除って言うならならきっちりかっちりまるっと全部消してしまえ！
と思うんだよなー
スレ趣旨と全然関係ないんだけどなー
615:nobodyさん
08/11/15 23:47:46
>>612
頭文字使うぐらいなら、enum型かSET型じゃね？
まぁ、DB実装によって違うかもしれんけど。
616:nobodyさん
08/11/16 02:05:02
論理削除はDELETEより早い速度が求められる場合(index更新のコストが馬鹿にならない)とか
警察照会とか、CS対応で必要とかやっぱり要るシーンが多くて>>614みたいに消してしまえーが使えない場合も少なくないよ
>>615
そうだね。
617:nobodyさん
08/11/16 02:08:47
論理削除っていう呼び方はおかしいね
ソフトウェアなんだから全て論理だし
無効化、凍結、と言う呼び方が正しい
618:nobodyさん
08/11/16 02:19:28
そうかな？英文でもphysical delete、logical deleteって言葉よく使われるよ。
URLﾘﾝｸ(publib.boulder.ibm.com)
619:nobodyさん
08/11/16 03:13:45
処理速度の場合もあるだろうけど、後から参照しないといけない場面がよくあるからな。安易に削除するわけにはいかないことが多い。
620:nobodyさん
08/11/16 06:39:55
だからそれを削除って呼ぶなよﾊﾞｰﾔ!!って言いたいんだろう
621:nobodyさん
08/11/16 06:56:48
論理削除を削除と呼ぶか、単なるステータスかというのは
呼び方の慣習の問題。
言葉遊びをやってもしょうがないんで、ここでは便宜的に、論理削除とは、
物理的には削除せずにサービス上削除されたようにふるまわせること
でいいかな？
622:nobodyさん
08/11/16 09:11:01
>>600 >>612
滔々と語ってるが、>>612の前者のdeleted （削除日時） はまあともかく、
後者の方では、レコードにユニーク制約のカラムがあった時に不便だろ。
削除フラグ（というかカウンタなど）とセットでユニーク制約にしてしまうって
のは、あんまり流行って無いのか？
623:nobodyさん
08/11/16 12:27:21
partial index 使っちゃう。
624:nobodyさん
08/11/16 12:33:30
>>622
詳しく
625:nobodyさん
08/11/16 13:00:36
>>624
例えばユーザアカウントをユニークにしたいとかで、一意制約をユーザ名カラムに付けるとする。
んで、そのユーザが退会した後、そのデータを残してたら、そのユーザ名がずっと使えない。
それを避けるために、削除データだけ一意制約から考慮外にしたい場合、削除フラグと２カラム連結で
ユニークにしてしまう。
んでレコードを削除する時に、同一なユーザ名を持つデータの削除フラグを、一斉に +1 UPDATEしてしまう。
削除フラグが 1以上なら( というか、0でなければ ) 削除データという扱い。
こんなやり方。マイナーなのかな？と思った。
書いてて思ったが、これ一意制約のカラムが二つ以上あった場合、そのままでは使えないなｗ
もちょっと応用を利かさないと無理か。
整数部分と少数部分で分けるとか桁で分けるとかビットで分けるとかｗｗｗ
＃ DBの一意制約を使わずアプリで常にチェックするなら別にこんなことしなくていいんだけど。
626:nobodyさん
08/11/16 13:06:04
こんな風にやりたいのなら、削除フラグ自体もユニークにして削除日時を
マイクロ秒まで入れておけばいいのではと後から思ったのは内緒だ。
627:nobodyさん
08/11/16 13:24:25
って書いて、削除フラグをユニークにしたらそもそも「未削除」の状態はどうするんだと気づいた午後。
飲みながらレスするもんじゃないな。
退散します。
628:nobodyさん
08/11/16 13:45:33
>>625
その例だと使えなくするケースが多いのでむしろ好都合。たいていサポートチームが要望してくる。
629:nobodyさん
08/11/16 13:51:02
酔っ払いめ！ｗｗ
さて、ユーザーアカウントを例にすると、ちょっと怖すぎるんだが、
CMSなんかのアイテム管理だと、リビジョン管理に同一itemidで
複数のインスタンス、しかも最新以外は非アクティブっていう状態を
表現するという用途があったりする。
その場合、削除フラグを使わずに、使用目的に合わせたタグを振る。
外部キー側もタグやリビジョン番号を考慮した設計にしないといかんわけだけどね。
630:nobodyさん
08/11/16 14:12:40
>>629
そういうのの設計はちょっと知りたいなーと思っていたんだけど、
MediaWikiのソースでも読めばいいのかな？
631:nobodyさん
08/11/16 14:19:46
PACの解説記事でDrupalが良い実装とか見たことあるので同じCMSならこっちは?
リビジョンと直接は関係ないけどソースはしっかりしてるかも
632:nobodyさん
08/11/16 14:26:24
設計見るのになぜソースを読む
633:nobodyさん
08/11/16 14:43:16
オープンソースソフトウェアの設計書なんて公開されてる？
634:nobodyさん
08/11/16 15:05:16
おそれすになったな・・・
>>587
> インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
> ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。
それをいったら、ウェブじゃないアプリだって、ほぼ画面（ディスプレイ）相手だろ？
なんか比較している対象がずれてるよ。
画面じゃなくてOffice系の大規模アプリだって、結局は画面にGUI表示してファイルに書き込むだけなんだし。
ゲームだってそう。ハードウェアデバイスを扱うものもあるだろうけど、それをウェブアプリでやってはだめってことはない。
ブラウザでコーヒー沸かす装置とかｗ
635:nobodyさん
08/11/16 15:05:49
>>633
設計書 = ソースコード
636:nobodyさん
08/11/16 15:33:36
>>634
元のレスが、アプリとは書いてなくて、「ウェブじゃないシステム」って書いてあるからじゃね？
対象がずれてるというか、「Office系の大規模アプリ」とかゲームとかが念頭にあるのは
わかっててわざと書いてるんだろｗ
車のエンジン制御とか、通信インフラ系とかはシステムじゃねーの？って。
>>585
> それにウェブじゃないシステムが何をしているかというと、
> 結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。
いえねーよｗ
これがむしろ、言いたいことと表現がずれてるんじゃね？
637:nobodyさん
08/11/16 17:24:18 +7h73lOI
タグの実装を考えています
スペース区切りでtextカラムに入れて、全文検索するのがシンプルでいいかと思ったのですが、
他にいい方法があったら教えてください
638:nobodyさん
08/11/16 17:26:45
>スペース区切りでtextカラムに入れて、全文検索
これはひどい
639:nobodyさん
08/11/16 17:28:47 +7h73lOI
そうですか？ググっていたら同じようなことしてる人もいますが。
URLﾘﾝｸ(blog.nomadscafe.jp)
他にいい方法があれば教えてください。
640:nobodyさん
08/11/16 17:43:46
タグ単位で編集とかしないならいいんじゃない？
641:nobodyさん
08/11/16 17:44:48
普通に考えれば
タグテーブル作って
アイテムテーブルとの間に多対多のリレーションテーブル持てばいいだけだよね
いかにもリレーショナルに解決出来るケースだと思うけど
642:nobodyさん
08/11/16 17:45:10
>>639
それ、フレームワーク関係ないし、それ以前にPHPの問題でもないよ。
DBの問題だからDB関連スレで質問しろよ。
まぁ、正規化すら理解してないみたいだからまずは本でも買って勉強することをオススメするけどね
643:nobodyさん
08/11/16 17:52:11
だね
基礎知識が足りてなさそう
644:nobodyさん
08/11/16 17:59:55
なるほど、おっしゃる通りですね。
ありがとうございました。
645:nobodyさん
08/11/16 18:01:45
俺はついこの間タグテーブルと、タグと記事のリレーションテーブルで作った。
けど、割とありきたりの機能になったのに、
情報が少なくてベストプラクティスな設計が出来たか不安なんだよね。
タグはパターンとしてどっかに情報がまとまっててもいいと思うんだが。
646:nobodyさん
08/11/16 18:10:11
だから典型的なリレーショナルな設計でいいでしょ
それ以外に特別な事なんて無いんだから
647:nobodyさん
08/11/16 18:20:02
うん基本的すぎてまとめる気が起きない
不安ってのはRDBの理解が不十分なのかと。
648:nobodyさん
08/11/16 18:26:03
フレームワークの話題が無いのか
649:nobodyさん
08/11/16 19:46:05
symfony使ってるんだけどRoRと比べてモデル周りが貧弱で泣いた
650:nobodyさん
08/11/16 20:18:46
PHPの場合、標準的なDBドライバがないからな。どれも中途半端。
651:nobodyさん
08/11/16 20:20:48
具体的にちんぽにーとrorでどうちがうの？
652:nobodyさん
08/11/16 20:23:39
横レスだけど。
RoRのアプリケーションはRubyで書けるけどSymfonyではRubyで書けない。
これは大きい。それに比べりゃモデル周りなんて大差ないんじゃね？
653:nobodyさん
08/11/16 20:25:04
んなの当たり前じゃん
フレームワークの比較より言語の比較だし
654:nobodyさん
08/11/16 21:54:05
フレームワークを初めてつかったけど「便利な関数群」ってだけじゃん。
655:nobodyさん
08/11/16 21:56:08
違うよ
全然違うよ
656:nobodyさん
08/11/16 21:59:31
>>654
なんという前世紀のライブラリ
まあそれはそれで便利だけど
657:nobodyさん
08/11/16 22:07:04 tiBOVYsk
PHPを初めてつかったけど「便利な関数群」ってだけじゃん。
658:nobodyさん
08/11/16 22:19:55
それはそうだよ
659:nobodyさん
08/11/16 22:21:24
>>657
それは半分真実
ただWEBフレームワークであるという視点も抜けている
例えば$_POSTや$_COOKIEは関数か？
HTTPヘッダを自動で吐く機能は関数？
PHPはただ単にWEB入出力とDBアクセスに便利な関数群装備のインタプリタとして
使うのもいいし、不十分な（でも拡張も可能な）フレームワークとしても利用出来る
と思ってるけどどうだろ
660:nobodyさん
08/11/16 23:54:00
フレームワークはパターンとルール
661:nobodyさん
08/11/17 00:16:53
それは多分定義のレイヤが違う
662:nobodyさん
08/11/17 00:19:03
>>661
どういうこと？
ｋｗｓｋ
663:nobodyさん
08/11/17 03:03:18
「便利な関数群」つうだけならそれはライブラリ。
ワークはあるがフレームがない。
664:nobodyさん
08/11/17 22:29:41
>>657
webプログラミングがまだ試行錯誤だった時代に、
その「便利な関数群」ってだけのことがとても
大きかったから、シェアが取れた。
便利な関数群自体がほとんど無かったからね。
Javaと同じ。
665:nobodyさん
08/11/18 03:06:59
$_SESSIONとか$_REQUESTとか勝手にcontent-typeが出力されるとか、PHPの言語機能自体にウェブアプリ用の機能が組み込まれてるからな。
666:nobodyさん
08/11/18 03:12:50
１回Ｃ言語でＷＥＢアプリ作ってみると良く分かる
あとＰＨＰが流行ったのはＷＥＢアプリ（のインタフェース部分）はこの程度の機能で十分って事もあるだろうね
敷居を低くしてしまって素人プログラマーが流入してきても
ＷＥＢ分野には受け皿がある
667:nobodyさん
08/11/18 06:22:10
webアプリなんて一方通行だからな
アホでも書けるんだよ
668:nobodyさん
08/11/18 10:11:51
>>664
関数や機能がたくさんあるだけが問題ならPerlが圧勝したはず。
やっぱりmod_phpの管理のお手軽さとPHPの言語自体の簡便さ。
669:nobodyさん
08/11/18 10:27:37
>>668
ソースインストールはお世辞にもお手軽とは言えなかったがな
未だにrpm以外でのPHP管理を敬遠するサーバ屋もあるくらい
670:nobodyさん
08/11/18 12:15:39
URLﾘﾝｸ(ja.wikipedia.org)
ここで言うプル型アーキテクチャのフレームワークってPHPでなんかある？
671:nobodyさん
08/11/18 12:41:48
Smarty
672:nobodyさん
08/11/18 13:20:30
なんか新しいフレームワークがでてきたらしい
Yii Web Programming Frameworkは期待できそう。
URLﾘﾝｸ(cakephp.seesaa.net)
673:nobodyさん
08/11/18 14:00:58
Perlは組み込み関数は少ない。
CPANモジュールをインストールしなければ行けないから、リモートログインとシェルが使えない共用のレンタルサーバなんかだと使い物にならない。
多少なりともUNIXの知識も要求されるし。
その点、PHPの場合、mbstringが有効になってれば、Pearが使えなくてもどうにでもなる。
674:nobodyさん
08/11/18 14:55:14
>>673
それはかなり昔の話だけどね。
PHPで global $HTTP_GET_VARS とかしなきゃいけない、ってのに近いくらいｗ
特に、Perl5.8からはEncode標準添付だし、MovableTypeの流行以降は、
そこらのレンタルサーバでも一通りのモジュールは入るようになってる。
DBI・DBMやらも普通に使えるのが大半。
その頃にはみんなレンタルサーバでのPerl CGIから離れてしまってたがなｗ
675:nobodyさん
08/11/18 14:59:41
>>670
よくわからんが、「イベントドリブン」なんてのを謳ってるようなのは
そうなのかな？
676:nobodyさん
08/11/18 18:21:34
>>672
ActiveRecordじゃないですか。モデルに強くてうれしす。
制作者はPRADOのひとかぁ
677:nobodyさん
08/11/18 19:49:11
>>675
EDPとはまた違うような。
ビューがコントローラーにデータをリクエストするようなやつ。
678:nobodyさん
08/11/18 20:42:37
PHPは5-6年前の時点でPHP4が普及してたから。
そもそも国際版のPHP3ってレンタルサーバで提供されることはほとんどなかった。あっても、すぐに4に移行したから。
Perlの場合、5.8.10になっても標準モジュールだけでは既存のウェブフレームワークは動かない。
モジュールをインストールしても、CatalystみたいなのはCGI環境ではまともな速度が出ないし。
共用レンタルサーバへの設置の難しさがあって、MTがWordPressに抜かれて、XOOPSとかPukiWikiとかフリーのウェブアプリってPHPの一人勝ちになった。
Perlが使われるのは未だにKENTのCGIとか。
そういう反省があって、今のPerl界でMENTAとかの設置の簡単な、標準外のモジュールに依存しないウェブフレームワークが注目されてる。
けど、結局のところ、ベストプラクティスに載ってるようなモダンなPerlを書こうと思えば、適時CPANモジュールをインストールするしかないわけで、これはPerlっていう言語の性格上どうにもならないな。
679:nobodyさん
08/11/18 20:49:25
>>677
ビューがコントローラーにデータをリクエストする。を読むと、
すごいイベント駆動ぽい気がするんだけど・・・
プル型というのは、いったい何のための仕組みなんだ？
コントローラーがビューにデータを渡すのではなく、
あえてビューがコントローラーにデータをリクエストする理由が知りたい。
680:nobodyさん
08/11/18 21:21:31
ページデザインだけでサイトが完結しうるところがメリットかな。
オンデマンドに必要なデータを拾いに行くので、自由度が高くなる。
ページに組み込むパーツがいかように変化してもコントローラーを
いじらなくて済むところとか。
まぁ、プッシュ型でも、ビューからコントローラーを呼べるはず。
それが特殊な時だけ利用するのか、常にそうするのかの違いだな。
CMSでイベント駆動だとプル型っぽい動きさせてるのが結構ある。
フレームワークはなんだかんだボトムアップだからプッシュ型が普通で、
それに慣れすぎてる感はある。
681:nobodyさん
08/11/18 22:15:34
あとプル型はコントローラーが複数あるのも特徴とか英文Wikipediaにかいてなかったっけ
なんかフレームワークスレっぽくなってきた
682:nobodyさん
08/11/18 22:23:17
英文関係無かった須磨祖
683:nobodyさん
08/11/18 22:54:01
あんまり詳しくないから変なこと言ってるかもしんないけど
PHPだと複数ファイルに分けてあるものをIncludeしてくしかないわけで、
MVCはコード書く上での概念みたいな感じでPushもPullも厳密には関係ないよね？
JavaServletのforwardみたいに処理投げ渡したりとかできないよね
684:nobodyさん
08/11/18 23:09:54
フレームワークが何を自動化するかって事だろ
685:nobodyさん
08/11/18 23:29:54
URLﾘﾝｸ(ja.wikipedia.org)
Tapestryではこんな説明だった。
> Apache Tapestryは、アクションをベースとした仕組みのApache Strutsとは競合する。
> TapestryはStrutsとは違い、コンポーネントベースであり、コード量が少なくて済む点が特徴である。
> またStrutsのようにJSPカスタムタグライブラリを覚えなおす必要がなく、
> 必ずServlet/JSPを作成しなければならないということはなく、
> Javaやネットワークの知識がないウェブデザイナーでも簡単にJava製ウェブアプリケーションを作成できるという利点がある。
アクションをベースとしたStrutsとは違うというあたりが、
なんとなくプル型が分かるような分からないような。
使ってみないと、はっきりしないかなー
686:nobodyさん
08/11/19 00:16:11
URLﾘﾝｸ(en.wikipedia.org)
これ見たらpush/pullが一目瞭然。
687:nobodyさん
08/11/19 00:34:10
Propelでmany-to-manyってどうやるの？
688:nobodyさん
08/11/19 02:02:44
URLﾘﾝｸ(ja.wikipedia.org)ソフトウェアコンポーネント
ここ読んでたらなんとなく分かってきた。
MVCからVを分離して、MCを部品として考えて、
Vから複数の部品を使うってことかな。
ショッピングカートの機能をMCだけ作って、
掲示板の機能もMCだけ作って、
コントローラとのインターフェースが分かってれば、
ビューでうまいことやるだけで、掲示板が組み込まれたECサイトの出来上がり。
語弊を恐れずに、俺の想像をざっくりと書いてみた。
//最近のブラウザはURLエンコードしてくれないのね。
689:nobodyさん
08/11/19 02:09:05
普通にwikipedia読めば分かるじゃん
690:nobodyさん
08/11/19 02:12:01
どのページ？
691:nobodyさん
08/11/19 03:03:05
>>688
そう
Vからプルするから主はV。結果、Vのみさわるデザイナーが使いやすいものとなる。
692:nobodyさん
08/11/21 13:07:50
ちんぽプルプルですね
わかります
693:nobodyさん
08/11/21 15:29:21
ですね分かりますは終了したってどっかに書いてあったよ
694:nobodyさん
08/11/21 15:35:48
どっかで終了宣言したら終わりなんですね
分かります
695:nobodyさん
08/11/22 10:57:11 enBp98lH
グレイトなMVCフレームワークないかい？
696:nobodyさん
08/11/22 11:55:27
あったら困らん
697:nobodyさん
08/11/22 13:29:05
ZF出たね
698:nobodyさん
08/11/23 02:16:27
yii使ってみた人いる？
699:nobodyさん
08/11/23 20:39:26
symfonyとcakePHPってどっちがいいの？
ユーザーは常時アクセス百人ぐらいを想定してます。
700:nobodyさん
08/11/23 20:41:14
そのレベルではどっちでも大して変わらんかと
701:nobodyさん
08/11/23 20:43:11
軽いっちゃあcakePHPだろうね。機能的にはsymfonyかね。
まぁそれぐらいの人数じゃ負荷は別に別に気にしなくてもいいと思うけどね。
702:nobodyさん
08/11/23 20:54:39
>>700>>701
回答ありがとうございます。
学習コストはどっちが大きいのかな？
symfonyの方が難しい？
703:nobodyさん
08/11/23 22:07:52
やりたいことにもよるだろ。
ドキュメントぐらい見ろや。
704:nobodyさん
08/11/23 23:03:02
自分でちょっとした軽いサイトを作りたいなてとき
CakePHPがよい
どういうサイトが当たるかわかんないから
とにかく当たりそうなサイトを片っ端から量産したいときにはCakePHPがいい
大企業からマジ受けするならsymfonyかな
そんな大企業を相手できない俺は小回りが利いて時代にニーズにいち早く対応できるCakePHPが一番好きだ
705:nobodyさん
08/11/23 23:03:07 I/SHm+AO
Cakeの方がインストール簡単
706:nobodyさん
08/11/23 23:06:24
CakePHPみたいに作りたいなと思ったサイトをサクッと作れる快感がたまらん
時代の流れの速いＩＴ業界にあってるよ
707:nobodyさん
08/11/24 00:43:30
おれはSymfonyの方がよりオブジェクト指向な分使いやすいな
ドキュメントもしっかりしてるし
708:nobodyさん
08/11/24 01:31:16
その二つのどっちかが今の主流なのかな
709:nobodyさん
08/11/24 01:58:00
今の日本での主流はcake。
php6の後も稼動し続ける予定ならZFが無難。
URLﾘﾝｸ(www.google.com)
検索数だからあてにならないかもしれないけど
日本語圏はcakeを世界で2番目に使ってるっぽいぞ。
つーか、地域だと目黒区が1位だけどお前ら寄付とかしてんの？ｗ
710:nobodyさん
08/11/24 02:07:28
インドネシア語が一位って。。
それ眉唾すぎないか
711:nobodyさん
08/11/24 02:19:05
ZFだけはないわ
cakeはドジでのろまな亀しか使ってないし
普通はsymfonyだろうな
712:nobodyさん
08/11/24 02:34:38
ちょろっとしか見なかったらなぜZFがあんな駄目駄目言われるかわからん。
みんな言うからきっとそうなんだろう。
713:nobodyさん
08/11/24 09:30:25
俺フレームワークの基礎にするには、別にZFは悪くない
symfonyは知らんが、cakeとかCIとかのように、「こう書けばすぐアプリ」っていう
がっちがちの枠を、ZFでは用意していないだけ。
714:nobodyさん
08/11/24 10:58:13
PEARみたいなライブラリということか
715:nobodyさん
08/11/24 12:21:02
密であるが疎にはできないものと
密にも疎にもできるもののどちらがいいかっていったら
そりゃ後者だわな
716:nobodyさん
08/11/24 13:41:57
そこら辺の凡人ＰＧがPHP4時代に書いたど腐れライブラリなんかは、
全部ZFに置き換えてもいいくらいだと思うよ
なんつーの？ 割り切り仕様というか内部諒解仕様というか、そういった
よくわからん決め打ち系の記述は（マルチバイト関連を除けば）非常に少なく、
かなり汎用的に作られてるっぽい。
例外処理だけ、ZF流儀にあわせればあとはどう使おうと自由って感じで。
717:nobodyさん
08/11/24 18:12:50
>>713
> がっちがちの枠を、ZFでは用意していないだけ。
がっちがちの枠（フレーム）を用意するのが
フレームワークだと思うんだがねぇ。
718:nobodyさん
08/11/24 18:28:09
メリットもあるが色々弊害もあるのだよ、僕
719:nobodyさん
08/11/24 18:35:08
それはフレームワークでなくて別って意味でしょう。
ZFは自由に使えって言うけどライブラリとの違いが分からない。
そして、結局ライブラリを細切れに使うのと手間が一緒の気がするんだけど。
それ以上のメリットがあるのか良く分からない。
720:nobodyさん
08/11/24 18:43:34
>>719
具体的にそれでどんな悪い点が？
721:nobodyさん
08/11/24 18:51:52
>>719
使ってみればわかるが、ZFにフレームはある。
ただ、それは固定されたフレームではなくて、設計者が自由に拡張可能なフレームだ
設計を行わない人にとっては無用の長物。メリットだってわからない。
722:nobodyさん
08/11/24 20:20:21
決め打ちでしかプログラミングできない低脳にはおすすめできないってこった
723:719
08/11/24 20:59:56
>>720
あえて言えばメリットが見つからないというのが悪い点かと
>>721
使い込んでみないと分からないって事でしょうか。
もうちょっと機会があれば研究してみたいとは思います。
>>722
なるほどそうですかw
724:nobodyさん
08/11/24 22:26:16
Eclipseでsymfonyフレームワーク使ってプログラミングしたいんだけど、可能？
725:nobodyさん
08/11/24 23:50:06
どういう意味かはっきり書かないと答えようがない。
Eclipseはエディタだからそりゃ可能だ。
726:nobodyさん
08/11/25 05:20:59
PDTで書けるかって意味ぢゃね？
ethnaとかちょっと微妙だから。
symofnyは大丈夫だけど、少しコツがいる。
けど、なんか安定しないんだよなぁ。もう1.2の声が聞こえてくるし。またコンバート作業必要なんでしょ？
＞ 1.1→1.2
727:nobodyさん
08/11/25 15:20:48
微妙って意味がわからんのだが
htmlまわりの話か?
728:nobodyさん
08/11/25 15:32:12
最近は知らんけど、1年くらい前の状況だと、
Ethnaの構造ではPDTでは補完が働かなかったな。
あとコマンドラインでアクションやビューやテンプレートが生成されるので、
いちいちプロジェクトを更新するのが面倒だった。
ファイルの追加がPDT外で行われて、PDTの補完も働かないんじゃ、
わざわざ重たいPDTを使うメリットがないと思った。
symfonyは使ってないからしらね。
729:nobodyさん
08/11/25 15:43:10
プロジェクトの更新なんてF5一発でいいのでは。
そんなこと言ってたらSVNでの頻繁な更新なんてできないじゃないかｗ
補完もどのみち最初から微妙っちゃ微妙だし。
少なくともPCパワーさえある程度あれば、テキストエディタよりは便利だと思う
まあやりやすいようにやればいいんだけど
730:nobodyさん
08/11/25 15:51:45
俺の場合、PDTに感じる価値がちょうどプロジェクトの管理と補完だからな。
逆にエディタとして見ると融通が利かない駄目なやつと思っている。
最近は出来るようになったけど、全角スペースをマーク表示させたり出来なかったとか、
後は覚えてないけど細かいところでたまにイラっとする。
だから俺は、プロジェクト管理と補完のために使ってるようなもんだ。
731:nobodyさん
08/11/25 16:09:13
一応、Eclipseの特徴として on the fly な構文チェックってのはあるけどね。
しょうもないparse errorとか、未定義変数とか示してくれるのは、非常に効率アップしてくれる
自分が注意力散漫だけかもしれんけどｗ
他のエディタでもこの機能はあるのかな？
732:nobodyさん
08/11/25 16:32:01
PDTにsymfony用のプラグインってあるよね
使ったことはないけど
733:nobodyさん
08/11/25 16:38:15
URLﾘﾝｸ(www.symfony-framework.com)
URLﾘﾝｸ(noy.cc)
Symfoclipseつーやつかな？
734:nobodyさん
08/11/25 16:54:55
てか、Eclipse使ってる人はPDTが多いのか。
なぜか理由は忘れたが、PHPEclipseの方を使ってる俺は異端？
735:nobodyさん
08/11/25 17:45:10
オレなんて未だにTruStudioなんだぜ、自宅は
さすがに会社はPDTに乗り換えたが、自宅じゃ
めんどくせーからこのまんまでいいやみたいな
736:nobodyさん
08/11/25 22:37:49
>>727
スケルトンが拡張子が.phpだから（かつ中身がphpじゃないから）PDTだとずっと構文エラーになる。
拡張子ハードコーディングしてあるから直せん＞ethna
737:nobodyさん
08/11/26 01:42:35
PDTならZSの方がインスコも楽だしアナライザーもはいる。
無料でよろし。お薦めする。
738:nobodyさん
08/11/26 05:16:43
Zend Studio？ 無料？
739:nobodyさん
08/11/26 08:31:02
そう。ZSは試用期間が終わるとPDTとほぼ同様になる。
尚日本語版は勧めない。日本語化したければPDTと同じようにする。
740:nobodyさん
08/11/26 21:22:21
>>736
うそ
ethnaって .php -> .html とかに変えられないの?
ダメだそりゃ
741:nobodyさん
08/11/27 02:26:51
>>740
スケルトンがな。
ルーティングなんていくらでも変えられる。
しかし、スケルトンもEthnaのデフォを削除しちゃって、自分Appのは
Handlerを定義しちゃえばいけるんじゃね？そんな手間でもないと思うが。
742:nobodyさん
08/12/01 22:29:43 XLqJXNnh
URLﾘﾝｸ(www.yiiframework.com)
Yii 178
CakePHP 170
CodeIgniter 131
Prado 53
Zend 51
Symfony 36
数字はRequest Per Second
743:nobodyさん
08/12/01 22:39:29
いいねいいね
今度使ってみるか
744:nobodyさん
08/12/01 23:19:54 XLqJXNnh
こういうhello worldにベンチってどんくらい意味あんのかとか思ってたけど
そのページに書いてあるようにあくまでRPSの上限を計るベンチで（これ以上の値は出ない）、
ajaxとかhtmlレンダリングない場合もあるしでやっぱり価値はある。
745:nobodyさん
08/12/01 23:27:25
そのベンチ、Yiiだけecho 'Hello World';になってて
他のがdie('Hello World');になってるのは何で？
まあ大抵のベンチは信用出来ないのは知ってるけども。
746:nobodyさん
08/12/01 23:48:49
dieの方が速いけどw
747:nobodyさん
08/12/02 01:49:03
なんでこんな速いの？エクステンション？
748:nobodyさん
08/12/02 01:54:30
URLﾘﾝｸ(phpimpact.wordpress.com)
Baseline PHP 331.8
CodeIgniter 21.5
Zend Framework 9.2
CakePHP 3.7
749:nobodyさん
08/12/02 10:55:00
ま た ベ ン チ パ フ ォ ー マ ン ス か
一応客観的っぽい比較はできるのかもしれないが、だからどうしたってんだ。
ってまだ誰も、使うどころか中を見てもないんだろうけどｗ
750:nobodyさん
08/12/02 11:15:02
>>749がコードを読んでパフォーマンスについての詳細な報告をしてくれるそうです
751:nobodyさん
08/12/02 11:40:29
"Yii is a high-performance component-based PHP framework for developing large-scale Web applications."
コンポーネント指向？ってどんな感じのを言うの？
752:nobodyさん
08/12/02 14:42:18
また新しいFWが登場したの？
みなさんのレポ（人柱）に期待ｗ
753:nobodyさん
08/12/02 15:26:34
G5の方がインテルより速いといい張ってた企業があったしな・・
ベンチマークなんて所詮うんちマークです
それが偉い人には分からんのです
754:nobodyさん
08/12/02 15:28:13
ボトルネックはDBまわりだったりするしな
755:nobodyさん
08/12/02 17:30:38
>>751
サービス指向と一緒にググるとよくわかる多分
756:nobodyさん
08/12/02 19:21:20
helloのベンチなんて高機能FWが不利に決まってるジャマイカ
757:nobodyさん
08/12/02 20:29:16
yiiって3メートル競走でフェラーリに勝ったと宣言する原付みたいだねm9（＾Д＾）ﾌﾟｷﾞｬｰ
758:nobodyさん
08/12/02 21:23:24
一応ActiveRecordやpure OOP、ドキュメントの整備なんかもウリにしてるみたい
=等の演算子にスペースをつけないとか if ～ else で { } を省略したり ?> を書かない
スタイルだったり、ところどころに小さなこだわり（？）を感じるｗ
demoしか見てないけど、Controllerの記述なんかはシンプルでいい感じ。（guessworkみたい？）
簡単なWebアプリなら、ドキュメント読まなくても何とかなるかな？
759:nobodyさん
08/12/02 21:47:13
ベンチって脊髄反射で熱くなるやつ多いよな
CakePHPのフォーラムとか
760:nobodyさん
08/12/02 21:58:40
>?> を書かない
これは当たり前だろ…
むしろ書く方がアホ
761:nobodyさん
08/12/02 22:06:13
>>759
> ベンチって脊髄反射で熱くなるやつ多いよな
ベンチに問題があることが多いからな。
762:nobodyさん
08/12/02 22:16:29 FW3sGcTR
まあ、symfonyは重すぎるな。
763:nobodyさん
08/12/02 22:27:41
>>749,753,754,756,757
I can hear the objections now:
* “Not realistic!”
* “Not comprehensive!”
* “Doesn’t account for features that I like!”
* “Who cares, I don’t need that level of responsiveness!”
* “Doesn’t matter if Framework X is slower, I’m more productive with it!”
Yes, yes, you’re all correct. ┐(´ー｀)┌
URLﾘﾝｸ(paul-m-jones.com)
764:nobodyさん
08/12/02 22:49:14
>>760
決めつける奴も(ry
------------------------------------
<?php
echo "hello\n";
------------------------------------
↑こういうの、気持ち悪くないか？そういう感覚を大事にしてる人間も結構な割合でいるぞ。
765:nobodyさん
08/12/02 22:56:45
>>764
それでいくと\nが気持ち悪い。ちゃんと書こうよ。
766:nobodyさん
08/12/02 23:11:14
ん？こうかな？
#!/usr/bin/php
<?php
echo "hello.\n";
767:nobodyさん
08/12/02 23:13:51
>>766
そのOS依存文字～!
\nだよ\n!!!
768:nobodyさん
08/12/02 23:13:52
凄いな･･･理解して書いてないよな。
769:nobodyさん
08/12/02 23:15:23
どっちも痛いけど>>767が果てしなく痛い
770:nobodyさん
08/12/02 23:16:48
>>769
ﾎｯﾄｹ
771:nobodyさん
08/12/02 23:19:22
>>766でOSの違いを吸収したつもりだったけど・・・OSXなんてしらね orz
PHP_EOLってのでいいのか
772:nobodyさん
08/12/02 23:26:39
>>771
Windowsはいいの？
URLﾘﾝｸ(side-b.sto.co.jp)
773:nobodyさん
08/12/02 23:29:12
さすがPerlなんともないぜ
774:nobodyさん
08/12/02 23:37:58
>>772
cygwinとかもしらね orz
（でもそれはLFでいいような気もする）
775:nobodyさん
08/12/02 23:52:13
VBですら定数あったな
776:nobodyさん
08/12/02 23:52:55
PHP_EOLはstr_replace(PHP_EOL,'<br />',$str)みたいな使い方するもんだろ。
PHP_EOLを出力に使うなよ。
PHPから抜け出して改行打った場合に、実行するOSによって
改行がバラけるだろ。
777:nobodyさん
08/12/02 23:55:24
タブやらヌルが一種類で本当によかったよな
778:nobodyさん
08/12/02 23:56:39
新説ktkr
779:nobodyさん
08/12/03 00:08:32
サーバのOSでの改行コードだから、両方関係ないだろ。
hello worldでPHP_EOL
見てる人のOSで改行されるとは限らない。
スクリプトで使ってる改行が実行サーバの改行コードと同じとは限らない。
str_replaceでPHP_EOL
見てる人のOSの改行コードがサーバと同じとは限らない。
780:nobodyさん
08/12/03 00:20:28
・・・見てる人？べつにブラウザ相手限定の話ではないとおもったが。
「スクリプトで使ってる改行」はPHPがなんか吸収してくれてるっぽいけどな。
LFでもCRLFでも動く。CRのみは知らないけどｗ
Perl CGI から移って最初のカルチャーショックはそれ。普通にLinuxマシンに
CRLFでアップロードしてるんじゃねーよって。
だから >>773 には半分だけ同意ｗ
>>776は新説。展開に期待しよう。
ブラウザがどの文字コードでどの改行コードでフォームデータを送ってくるか、
その辺もそろそろ定義および実装してほしいもんだ。
現状、なんとなく、UTF-8のページからは（ユーザの悪意がなければ）UTF-8で
飛んでくることを期待して作ってしまうんだが大丈夫なのかな・・・。
改行コードは仕方ないから変換するけど。
スレ違いｽﾏｿ
781:nobodyさん
08/12/03 00:23:14
Perlだったらjcode.plとかJcode.pmとかEncodeとかあるだろうよ。
782:nobodyさん
08/12/03 00:25:19
guess して不明なら全部はねる？
まあそういう作り方もあるだろうけどね
783:nobodyさん
08/12/03 00:53:25
文字コードは、RFCでサーバが出力した文字コード以外でPOSTしても
違反ではない事になってるんだな。
accept-charsetっていうのもあるけど、対応して無いブラウザもある。
被ってる領域内の文字しか無かったら判別は不可能なのにね。
実際は大抵のブラウザはヘッダの指定と同じ文字コード送ってくれるし
mb_conbertとかで優先順の1位を出力にあわせればまず平気だけども
イレギュラーなブラウザは存在する。
あとはhiddenで文字コード判別出来る文字列送るって方法もある。
英語圏なら全てctypeでOKなのにな。
RFCもブラウザ作ってる奴も文字コード増やしてる奴も爆発しろ。
784:nobodyさん
08/12/03 00:57:25
イレギュラーなブラウザなんて少ないんだからそこらへんは趣味じゃない
785:nobodyさん
08/12/03 03:25:54
でも、何となくいけてるだけっていうのに違いはないんだよね
まあ判別して不明なら受け入れるっていうのが慎重かつ幅広い対応なんだろうな
んで、Yiiはどこに行ったんだ。実は少し期待してるんだけど。
786:nobodyさん
08/12/03 05:58:13
結局はちいたんで（ｒｙ
787:nobodyさん
08/12/03 10:22:38
>>763
symfonyは他のに比べて読み込むファイルが多すぎなんだよな。
788:nobodyさん
08/12/03 11:40:40
PHPFWの色々な比較みたいなのやってるサイトとかないかねぇ
789:nobodyさん
08/12/03 13:57:38
>>788
なんの比較?